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16.  Abstract 


This  report  contains  results  of  tests  performed  in  an  environment  of  multiple 
Discrete  Address  Beacon  System  (DABS)  sensors,  one  each  located  at  Clementon  and 
Elwood,  New  Jersey,  and  the  Federal  Aviation  Administration  (FAA)  Technical  Center, 
Atlantic  City  Airport,  New  Jersey.  These  DABS  sensors  were  tested  in  various  degrees 
of  intersensor  communication  that  ranged  from  a  full  network  of  connected  sensors  to  a 
fully  nonnetted  configuration. 

The  multiple  DABS  sensors  were  tested  in  four  major  areas:  network  management, 
surveillance  processing,  data  link  processing,  and  intersensor  communications. 

It  is  concluded  that  the  performance  of  the  DABS  sensors  in  multisite  configurations 
meets  or  exceeds  the  requirements  specified  in  the  DABS  engineering  requirement 
(FAA-ER-240-26) . 
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INTRODUCTION 


PURPOSE. 

This  report  is  one  of  a  series  of  test 
reports  issued  by  the  Federal  Aviation 
Administration  (FAA)  Technical  Center  on 
the  performance  of  the  Discrete  Address 
Beacon  System  (DABS).  An  earlier  report 
(FAA-RD-80-36/FAA-NA-79-52,  "Discrete 
Address  Beacon  System  (DABS)  Baseline 
Test  and  Evaluation")  addressed  the 
results  obtained  from  tests  performed  on 
a  single  DABS  sensor  operating  in  a 
stand-alone  mode.  The  subject  of  the 
current  test  activity  is  the  performance 
of  the  DABS  operating  in  a  multiple 
sensor  environment.  The  DABS  system 
was  evaluated  with  respect  to  four 
functional  areas:  network  management, 
aircraft  surveillance,  performance 
of  the  air/ground  data  link,  and 
s e n s o r- t o- s e n s o r  communications. 
The  multiple  sensor  environment  for 
these  tests  was  configured  with  various 
degrees  of  intersensor  communication 
that  ranged  from  a  full  network  of 
landline  telephone  communication  among 
the  sensors  to  a  fully  nonnetted 
configuration. 

Analysis  was  undertaken  with  two 
objectives  in  mind:  (1)  the  evaluation 
of  system  performance,  and  (2)  the 
verification  that  the  network  concept 
is  workable. 

BACKGROUND . 

The  necessity  for  the  development  of  the 
DABS  was  identified  in  a  1969  study 
conducted  by  the  Department  of  Trans¬ 
portation's  Air  Traffic  Control  Advisory 
Committee.  The  study  recommended  that 
the  present  Air  Traffic  Control  Radar 
Beacon  System  (ATCRBS)  be  upgraded  to 
provide  the  capability  for  communicating 
with  discretely  addressable  airborne 
transponding  equipment.  The  existence 
of  a  unique,  discrete  address  would 
allow  individual  interrogation  of  each 
aircraft  so  equipped,  and  would  support 


the  idea  of  a  private  two-way 
communications  channel  (or  "data  link") 
between  the  airborne  unit  and  the 
ground.  The  study  further  recommended 
the  development  of  a  ground-based 
collision  avoidance  system  that  would 
use  the  data  link  to  send  traffic 
advisory,  threat  assessments,  and 
maneuver  commands  to  aircraft  on 
potential  collision  courses. 

The  subsequent  development  of  the  DABS 
has  followed  the  plan  which  is  detailed 
in  the  Engineering  and  Development 
Program  Plan  FAA-ED-03-1 .  The  first 
phase  began  in  January  1972,  with  a 
contract  award  to  the  Massachusetts 
Institute  of  Technology  (MIT)  Lincoln 
Laboratory  for  development  of  an 
experimental  model  of  DABS.  This 
effort  demonstrated  the  feasibility 
of  the  concept  and  resulted  in  the 
development  of  a  set  of  engineering 
requirements  (FAA-ER-240-26)  that  were 
used  to  procure  three  DABS  Engineering 
mode 1 s . 


DISCUSSION 


DESCRIPTION  OF  EQUIPMENT. 


THE  DABS  CONCEPT.  The  DABS,  in  addition 
to  being  compatible  with  the  present 
ATCRBS  system,  provides  six  basic 
improvements.  These  improvements  are: 
(1)  upgrade  of  ATCRBS  surveillance 
by  employing  a  monopulse  processing 
technique,  (2)  discrete  interrogation  of 
DABS  equipped  aircraft,  (3)  air-ground 
data  link  for  support  of  ATC  automation, 

(4)  increased  surveillance  capacity, 

(5)  improved  tracking  accuracy,  and 

(6)  redundant  surveillance  coverage  in 
the  event  of  adjacent  sensor  failure. 

Existing  ATCRBS  transponders  require  no 
modification  in  order  to  continue  at 
their  current  level  of  functioning  in 
the  new  DABS/ATCRBS  environment,  thus, 
allowing  for  an  economical  transition 
from  the  present  ATCRBS  environment  to 
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Che  DABS  environment  of  the  future. 
Immediate  benefits  arising  from  improved 
ATCRBS  surveillance  are  realized  totally 
from  changes  in  the  ground-based 
equipment.  The  addition  of  monopulse 
processing  provides  greater  accuracy  and 
increased  resolution  of  two  closely 
spaced  ATCRBS  replies,  and  fewer  replies 
are  required  to  accomplish  the  tasks  of 
target  detection  and  code  validation. 
The  pulse  repetition  frequency  (PRF)  of 
the  interrogation  is  reduced  which, 
in  turn,  results  in  a  corresponding 
reduction  in  the  level  of  asynchronous 
replies  (fruit). 

For  DABS  equipped  aircraft,  each 
transponder  is  assigned  a  unique 
address  and,  in  the  normal  mode  of  use 
known  as  roll-call,  responds  only  to 
interrogations  containing  that  discrete 
address.  Aircraft  are  initially 
detected  in  a  sensor's  surveillance  area 
by  their  responses  to  All-Call  interro¬ 
gations  in  which  the  transponder  reports 
its  discrete  code.  Upon  receipt  of  the 
correct  number  of  All-Call  responses 
from  an  aircraft,  the  sensor  places  the 
aircraft  in  roll-call  mode.  If  the 
sensor  has  a  status  of  "primary,"  with 
respect  to  that  aircraft,  it  locks 
out  the  transponder  from  responding 
to  further  All-Call  interrogations. 
Primary  status  is  assigned  by  air 
traffic  control  (ATC)  or  is  determined 
by  the  geographical  position  of  the 
aircraft  and  requires  the  sensor  to  read 
downlink  messages  from  an  airborne 
transponder  in  addition  to  performing 
the  lockout  function. 

Each  sensor  may  provide  surveillance  and 
communication  services  to  specified 
ATC  facilities.  Radar  and  beacon 
surveillance  data  are  transmitted 
from  the  sensor  to  a  facility  on  a 
one-way  channel.  Other  communications 
between  the  facility  and  the  sensor  or 
between  the  facility  and  the  aircraft 
make  use  of  a  two-way  interface. 

DABS  sensors  may  be  netted  to  each  other 
with  two-way  communication  links  when 
overlapping  or  adjacent  geographical 


coverage  provides  the  advantages  to  be 
realized  from  creating  a  multiple-sensor 
network.  Such  advantages  include 
redundant  coverage  in  the  event  of 
failure  of  one  site  and  tracking 
assistance  for  sensors  experiencing 
transponder  fade  as  a  result  of  antenna 
shielding  or  cone-of-silence  entry.  The 
sensors  are  also  capable  of  operating  in 
the  so-called  "stand-alone"  mode,  in 
which  they  are  not  netted  to  each  other 
but  must  operate  in  areas  of  overlapping 
coverage.  Failure  of  a  communications 
link  between  two  operating  sensors  will 
result  in  a  de  facto  entry  into  the 
stand-alone  mode. 

DABS  SENSORS.  Each  DABS  sensor  is 
composed  of  an  interrogator/processor 
(I&P)  front  end  which  contains  the 
transmitter  unit  (MCU);  the  reply 
processors  (one  each  for  DABS  and 
ATCRBS);  the  azimuth  system  timing  unit 
(AZSTU),  which  interfaces  to  the  antenna 
shaft  encoder  and  to  a  WWVB  receiver; 
and  a  performance  monitor,  which  samples 
such  I&P  performance  items  as  the 
transmitter  power,  receiver  gain, 
receiver  noise,  and  monopulse  values. 
The  I&P  section  has  been  expanded  at  the 
Technical  Center  site  to  include  inputs 
from  either  moving  target  generator 
(MTD)  or  radar  data  acquisition 
subsystem  (RDAS)  radar,  the  choice  to  be 
made  when  the  system  is  initialized. 

The  I&P  hardware  is  interfaced  to  a 
distributed  computer  system  containing 
36  minicomputers,  most  of  which  are 
organized  into  groups  (or  ensembles)  of 
four  computers  interfaced  to  a  local 
data  bus.  Most  ensembles  are  coupled 
between  two  global  data  buses,  which  are 
used  to  gain  access  to  a  common  global 
memory  containing  program  store,  data 
base,  and  the  address  space  of  the  I&P. 

One  of  the  ensembles  is  designed 
especially  for  handling  the  required 
communications  between  the  sensor  and 
ATC  facilities  and  the  additional  commu¬ 
nications  required  for  sensor-to-sensor 
communications  in  a  DABS  network. 
Another  ensemble  is  dedicated  to 


the  processing  of  ATCRBS  replies.  A 
functional  block  diagram  of  a  DABS 
sensor  is  shown  in  figure  1. 

TEST  EQUIPMENT.  Items  of  test  equipment 
used  in  performance  evaluation  were 
the  system  test  console  (STC)  and 
the  Aircraft  Reply  and  Interference 
Environment  Simulator  (ARIES) . 

System  Test  Console.  The  STC, 
located  at  the  Technical  Center,  is  a 
data  entry  and  display  device  devoted 
exclusively  to  DABS.  It  consists  of  an 
ATC  type  display  and  keyboard  and  a 
computer  subsystem,  which  monitors 
in  real  time  all  communication  and 
surveillance  lines  in  the  DABS  network 
and  displays  and/or  records  on  magnetic 
tape  those  data  which  have  been 
specified  by  the  operator.  Under 
keyboard  command,  the  STC  is  capable 
of  displaying  surveillance  data 
disseminated  from  any  individual  sensor 
or  that  disseminated  from  all  sensors 
simultaneously.  Keyboard  commands  are 
also  used  to  determine  which  data  shall 
be  selected  for  recording. 

The  STC  can  also  be  used  as  a 
simulated  ATC  facility,  permitting  an 
operator  to  generate  uplink  messages  to 
an  aircraft,  either  in  real  time  or  by 
running  a  prerecorded  message  scenario. 
Uplinks  sent  to  the  DABS  sensor  are 
recorded  on  the  STC  tape,  as  are  the 
responses  returned  from  the  sensor  to 
the  STC.  The  message  generation  and 
recording  capability  is  useful  in 
exercising  the  data  link  between 
the  DABS  sensor  and  a  DABS-equipped 
aircraft . 

Additional  ATC  functions  for  which 
the  STC  has  been  used  include  generation 
of  aircraft  control  state  messages  used 
to  designate  a  DABS  aircraft  as  a 
controlled  target  (see  "Controlled 
Targets  section"  of  "Descriptions  of 
Equipment")  and  generation  of  sensor 
fai  lure/recovery  messages.  Sensor 
failure/ recovery  messages  provide 
the  user  with  a  convenient  means  of 


reconfiguring  a  sensor's  coverage  by 
telling  it  that  one  or  more  of  its 
neighbors  within  the  network  has  failed. 

Aircraft  Reply  and  Interference 
Environment  Simulator.  The  ARIES  is 
an  automated  device  for  supplying  the 
DABS  sensor  with  replies  to  DABS  and 
ATCRBS  interrogations.  It  may  be  used 
by  itself  or  superimposed  upon  real 
world  inputs.  The  user  of  the  ARIES 
specifies  a  scenario  in  which  a  mixture 
of  simulated  DABS  and  ATCRBS  aircraft 
exist,  each  one  having  a  certain  initial 
position  and  velocity.  Depending  upon 
the  means  used  for  scenario  generation, 
aircraft  trajectories  may  be  specified 
and  the  downlink  message  bit  ("B-bit") 
may  be  set  in  the  simulated  DABS 
replies,  causing  the  DABS  sensor  to 
exercise  the  downlink  message  retrieval 
mechanism.  Fruit  generators  allow 
simulation  of  various  levels  of  DABS  and 
ATCRBS  fruit.  The  two  ARIES  units,  one 
located  at  the  Technical  Center  and  one 
located  at  Elwood,  may  be  used  either 
to  supplement  or  to  substitute  for  real 
world  inputs  to  the  DABS. 

ARIES  scenarios  have  been  used 
extensively  in  previous  baseline 
testing,  in  conflict  analysis,  and  in 
capacity  testing,  since  loads  of  up  to 
400  targets  in  any  DABS/ATCRBS  mixture 
can  be  provided.  The  present  multisite 
testing  effort  has  made  use  of  the  fruit 
generation  capability  of  the  ARIES. 
Future  multisite  tests  will  involve 
communication  between  the  two  ARIES 
units  to  simulate  the  behavior  of 
DABS  transponders  in  an  environment  in 
which  they  are  subject  to  lockout  by  the 
two  participating  DABS  sensors. 

DESCRIPTION  OF  SYSTEM. 

SYSTEM  CONFIGURATION.  The  three  DABS 
sensors  are  connected  to  each  other 
and  to  the  system  test  console  at 
the  Technical  Center  by  means  of 
dedicated  telephone  lines.  One  pair  of 
bidirectional  lines  is  used  to  connect 
the  Technical  Center  sensor  with  Elwood, 
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FIGURE  I.  DABS  SENSOR  FUNCTIONAL  BLOCK  DIAGRAM 


one  pair  is  used  to  connect  Elwood  with 
Clementon,  and  one  pair  is  used  to 
connect  Clementon  back  to  the  Technical 
Center.  A  single  bidirectional  line 
connects  Elwood  with  the  STC.  A  similar 
line  allows  communication  between 
Clementon  and  the  STC.  Since  the  STC  is 
collocated  with  the  Technical  Center 
sensor,  telephone  connections  are  not 
required  and  the  communication  takes 
place  across  direct  lines. 

Three  communication  lines  exist  between 
each  of  the  sensors  and  each  of  two 
simulated  ATC  facilities:  the  System 
Support  Facility  (SSF)  and  the  Terminal 
Automation  Test  Facility  (TATF).  Two  of 
the  three  lines  are  one-way  surveillance 
lines  that  carry  target  reports  and 
radar  messages.  The  third  line  is 
bidirectional  and  is  used  for  message 
exchange  using  the  Common  International 
Civil  Aviation  Organization  (ICAO)  Data 
Interchange  Network  (CIDIN)  protocol. 
The  SSF  is  capable  of  communicating 
with  all  three  sensors  during  the 
same  run.  However,  the  TATF  has  only 
one  port,  which  restricts  it  to 
servicing  only  one  user  during  a  given 
test . 

When  located  within  surveillance  range 
of  a  given  target,  multiple  DABS  sensors 
provide  redundant  surveillance  coverage 
to  insure  continuity  of  tracking  in  the 
event  of  the  failure  of  a  DABS  site, 
during  target  fade  conditions  arising 
from  antenna  shielding,  or  operations 
conducted  within  the  sensor's  cone  of 
silence.  Essential  to  the  successful 
maintenance  of  redundant  coverage  is 
the  DABS  function  known  as  network 
management.  It  is  one  of  the  four  DABS 
functions  which  were  evaluated  in  a 
live,  multiple  sensor  environment  as 
a  basis  for  the  present  report.  The 
other  three  functions  are  surveillance 
processing,  data  link  processing,  and 
intersensor  communications. 

NETWORK  MANAGEMENT  -  CONCEPTS  AND 

DEFINITIONS .  The  purpose  of  the  network 
management  function  is  to  provide 
coordination  between  the  sensors  in 


regions  of  redundant  surveillance 
coverage.  The  exact  nature  of  this 
coordination  depends  upon  whether 
or  not  the  sensors  are  connected  to  each 
other  by  landlines. 

Connected  Sensors.  When  redundant 
surveillance  coverage  occurs  between 
or  among  sensors  which  are  connected  to 
each  other,  network  management  provides: 

1.  Acquisition  assistance  on  a 
target  entering  another  sensor's 
coverage  (handoff). 

2.  Tracking  assistance  for  a 
sensor  whose  target  has  faded. 

3.  Coordination  between  sensors  to 
determine  which  sensor  is  "primary" 
for  each  uncontrolled  DABS  target.  A 
primary  sensor  is  responsible  for 
obtaining  readout  of  pilot-initiated 
downlink  (Comm  B  and  Comm  D)  messages, 
for  locking  out  DABS  transponders  to 
All-Call  interrogations,  and  for  issuing 
synchronized  interrogations  if  required. 

Unconnected  Sensors.  In  cases 
where  redundant  surveillance  coverage 
is  provided  by  sensors  which  are  not 
connected  to  each  other  by  operational 
landlines,  network  management  reverts  to 
its  "stand-alone"  mode.  In  this  mode, 
lacking  a  communication  link,  the 
network  management  function  provides: 

1.  A  scheme  of  intermittent  lock 
and  unlock  of  the  ATCRBS/DABS  All-Call 
state  so  that  unconnected  sensors  may 
acquire  or  reacquire  a  DABS  aircraft 
without  external  assistance. 

2.  An  assignment  of  primary 
responsibility  for  an  uncontrolled  DABS 
target  based  solely  on  its  geographical 
location.  In  the  unconnected  mode  it  is 
expected  that  multiple  sensors  will  have 
primary  responsibility  in  areas  where 
their  internal  coverage  maps  dictate 
that  overlapping  coverage  exist. 

Partial  Connectivity.  In  surveil¬ 
lance  regions  where  mixtures  of 
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connectivity  occur  (e.g.,  two  sensors 
connected  and  one  unconnected),  the 
network  management  function  must  provide 
appropriate  behavior  with  respect  to  the 
connectivity  state  of  each  neighboring 
sensor. 

Controlled  Targets.  Regardless  of 
intersensor  connectivity,  a  controlled 
target  depends  upon  the  cognizant  ATC 
facility  for  its  primary  or  secondary 
specification.  The  network  management 
function  overrides  the  current  sensor 
priority  status  with  the  value  specified 
by  the  content  of  the  most  recent 
aircraft  control  state  message  received 
from  ATC. 

THE  SURVEILLANCE  PROCESSING  FUNCTION. 
The  su'/veillance  processing  function  is 
responsible  for  the  tracking  of  targets 
within  the  sensor.  This  function  has 
undergone  a  few  minor  changes  between 
the  time  of  the  baseline  testing 
discussed  in  report  FAA-RD-80-36 ,  for 
which  software  release  6.3  was  used,  and 
the  DABS  multisite  testing  contained  in 
this  report  for  which  release  7.2  was 
used.  These  changes  were  primarily 
concerned  with  ATCRBS  performance  and 
were  expected  to  have  little,  if  any, 
effect  on  the  observed  behavior  of  DABS. 
These  changes  are  summarized  below. 

1.  A  fixed  jitter  was  added  to  the 
pulse  repetition  frequency  (PRF)  in 
order  to  avoid  site-to-site  interference 
among  the  three  DABS  sensors ,  which 
operate  at  the  same  basic  PRF.  If  this 
change  was  to  result  in  an  observable 
difference,  it  would  be  expected  to  make 
a  slight  reduction  in  the  number  of 
interrogations  issued  and  improve  the 
number  of  replies  needed  for  declaration 
of  a  report . 

2.  The  effective  receive  beam  width  was 
increased  from  2. A"  to  3.5°,  primarily 
to  increase  the  number  of  replies 
available  for  use  in  declaration  of 
ATCRBS  reports.  If  this  increase  was  to 
have  an  effect  on  DABS  surveillance 
performance,  it  might  be  visible  as  a 


lower  re interrogation  rate  because  of 
an  increased  probability  of  receiving 
usable  replies  at  the  leading  edge  of 
the  beam. 

3.  A  new  ATCRBS  target-to-track 
associator/cor relator  was  added  in  order 
to  fix  a  timing  problem  involving  the 
dissemination  of  nondiscrete  ATCRBS 
targets  to  noncorrelating  ATC  users. 
All  such  targets  are  now  automatically 
held  for  four  sectors,  thus,  increasing 
the  percentage  of  late  disseminations. 
This  change  has  no  apparent  relationship 
to  DABS. 

The  most  significant  change  between 
release  6.3  and  release  7.2  was  the 
inclusion  of  an  upgraded  network 
management  function  (described  in  the 
previous  section). 

THE  DATA  LINK  PROCESSING  FUNCTION.  The 
data  link  processing  function  manages 
the  communications  that  take  place 
between  a  DABS  aircraft  and  the 
ground-based  users  of  the  system,  which 
currently  include  the  Automatic  Traffic 
Advisory  and  Resolution  Service  (ATARS) 
function  and  ATC  en  route  and  terminal 
facilities.  Messages  may  originate  on 
the  ground,  in  which  case  they  are 
addressed  to  a  specific  DABS  aircraft, 
or  they  may  originate  in  the  air  for 
dissemination  to  all  "appropriate" 
facilities  as  determined  from  a 
site-adaptable  table  within  the  sensor. 
A  tactical  downlink  message  from  an 
aircraft  contains  56  bits  of  message 
data.  A  tactical  uplink  message 
originated  by  a  ground-based  user  may 
contain  up  to  four  56-bit  segments  to  be 
sent  to  the  aircraft  as  four  "standard 
length"  uplink  messages.  Some  DABS 
transponders  have  the  capability  for 
sending  and  receiving  extended  length 
messages  (ELM's),  which  may  contain  as 
many  as  sixteen  112-bit  segments  and  are 
sent  on  the  data  link  using  special 
transactions,  one  per  segment.  This 
report  addresses  testing  of  the  standard 
length  messages  only. 


Messages  are  handled  by  two  distinct 
parts  of  the  data  link  function:  the 
input  message  processor  and  the  output 
message  processor. 

Input  Message  Processor.  The  input 
message  processor  performs  an  acceptance 
check  on  incoming  messages.  If  the 
message  is  addressed  to  an  aircraft 
which  is  not  in  the  surveillance  file, 
the  message  is  discarded  and  a  rejection 
notice  is  sent  to  its  originator.  If 
the  target  is  in  the  surveillance  file 
but  is  not  in  the  roll-call  state,  the 
message  is  placed  on  the  uplink  queue 
and  a  message  delay  notice  is  sent  to 
the  originator  as  a  warning  that  the 
sensor  is  temporarily  unable  to  deliver 
it.  For  a  target  that  is  being  tracked 
in  the  roll-call  state  the  message  is 
placed  on  queue  for  delivery. 

Output  Message  Processor.  The 
output  message  processor  is  responsible 
for  informing  the  originator  of  an 
uplink  message:  (1)  that  the  message 
was  successfully  transmitted  to  the 
aircraft,  or  (2)  that  the  expiration 
time  contained  within  the  message  was 
exceeded  and  the  message  was  discarded. 
If  downlink  messages  were  received  in 
conjunction  with  the  replies  from  the 
DABS  aircraft,  the  output  message 
processor  is  responsible  for  extracting 
the  data  and  forwarding  it  to  the 
appropriate  ground-based  user(s). 

INTERSENSOR  COMMUNICATIONS.  Additional 
functions  which  are  used  in  a  multi¬ 
sensor  environment  are  responsible  for 
making  periodic  checks  on  the  status  of 
connected  sensors.  If  status  messages 
are  not  received  each  scan  from  a 
neighboring  connected  sensor,  a  process 
of  inquiry  is  begun  which  is  designed  to 
help  the  local  sensor  "infer"  the  status 
of  the  missing  sensor.  Other  members  of 
the  net  are  asked  for  what  information 
they  may  have  about  the  status  of  the 
sensor  in  question,  and  this  information 
is  used  in  assigning  to  the  missing 
sensor  the  status  of  "inferred  failure" 
(in  which  case  the  missing  sensor  is 


treated  as  failed),  or  "inferred 
communications  failure"  (in  which  case 
the  missing  sensor  is  treated  as  if 
it  were  unconnected).  A  missing  sensor 
about  which  no  judgment  can  be  made  is 
left  in  a  status  known  as  "loss  of 
message"  and  treated  as  if  it  were 
operational  but  unconnected.  A  "failed" 
sensor  is  one  which  has  either  reported 
its  own  failure  by  sending  a  "red" 
sensor-to-sensor  status  message  or  which 
has  been  reported  as  failed  by  an  ATC 
facility.  In  order  to  detect  the 
recovery  of  a  failed  sensor  (whether  it 
was  a  reported  failure  or  an  inferred 
failure),  the  sensor  continues  to  send 
out  periodic  inquiries  to  all  the 
remaining  members  of  the  net. 

When  any  adjacent  sensor  has  been 
judged  by  one  of  these  means  to  be  in  a 
state  of  failure,  the  network  management 
function  operates  in  what  is  known  as 
the  "special  mode."  This  involves 
reading  the  coverage  map  in  such  a  way 
as  to  omit  the  failed  sensor  from 
consideration  in  building  the  adjacent 
sensor  assignment  lists  and  determining 
which  sensor  should  have  primary 
responsibility.  The  special  mode  is 
the  meanB  used  by  DABS  to  cover,  insofar 
as  possible,  the  network  management 
responsibilities  of  missing  sensors. 

Each  local  sensor  is  also  required  to 
make  periodic  requests  for  surveillance 
data  on  the  calibration  and  performance 
monitoring  equipments  (CPME's)  of  each 
connected  neighbor.  Should  the  known 
position  of  one  of  these  fixed  targets 
slip  too  far  out  of  tolerance,  the  local 
sensor  is,  thus,  made  aware  of  the 
condition  and  will  report  it  to  its 
cognizant  ATC  facility.  No  other 
operational  action  concerning  adjacent 
CPME's  is  currently  specified  for  the 
local  sensor. 

TEST  CONFIGURATION. 

SENSOR  NETWORK  CONFIGURATIONS.  Because 
there  are  different  reactions  of  the 
network  management  function  to  the 
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presence  of  connected  or  unconnected 
sensors,  various  configurations  of 
one,  two,  and  three  DABS  sensors  were 
used  for  testing  and  evaluation.  The 
combinations  that  were  tested  were 
selected  to  reflect  the  fact  that  two 
of  the  sensors  are  configured  to  operate 
as  terminal  sensors,  having  a  nominal 
60-nautical  mile  (nmi)  coverage  radius, 
an  antenna  scan  rate  of  4.7  seconds,  and 
a  single  antenna  face.  The  other 
sensor,  located  at  Elwood,  is  configured 
for  en  route  operation  having  a  nominal 
200-nmi  coverage  and  two  identical 
beacon  antennas  in  a  back-to-back 
configuration,  which  provides  an 
effective  scan  rate  of  4.8  seconds. 
The  200-nmi  coverage  was  reduced,  for 
test  purposes,  to  60  nmi  in  order  to 
reduce  the  data  load  at  the  STC. 
Because  the  specified  size  of  the  STC 
is  400  targets  (total),  only  133  targets 
may  be  received  from  each  of  the  three 
sensors  before  target  reports  are 
discarded . 

Tests  were  also  performed  on  single 
unconnected  sensors  as  well  as  on  the 
following  multisite  configurations.  Any 
sensors  not  par t ic ipa t i ng  in  a  test 
configuration  were  declared  to  be  in  a 
state  of  failure  through  generation  of 
the  appropriate  sensor  failure  messages 
at  the  STC. 

Two-Sensor  Configurations.  The 
two-sensor  configurations  tested  were 
as  follows: 

1.  Two  terminal  sensors  (Technical 
Center  and  Clementon),  both  connected 
and  unconnected. 

2.  En  route  sensor  (Elwood)  and 
one  terminal  sensor  (Technical  Center), 
both  connected  and  unconnected. 

Three-Sensor  Configurations. 
Several  three-sensor  conf igurat ions 
were  tested  as  follows: 

1.  Three  sensors,  all  connected 
and  all  unconnected. 


2.  Two  terminal  sensors  (Technical 
Center  and  Clementon),  connected  to 
each  other,  en  route  sensor  fully 
unconnected . 

3.  One  terminal  sensor  and  the 
en  route  sensor  (Technical  Center  and 
Elwood)  connected  and  the  other  terminal 
sensor  (Clementon)  fully  unconnected. 

4.  Fully  connected  except  for  the 
terminal/terminal  connection  (Technical 
Center-Clementon  link  broken). 

5.  Fully  connected  except  for 
one  terminal/en  route  connection 
(Clementon-Elwood  link  broken). 

No  appreciable  difference  in 
test  results  was  expected  when 
substituting  the  en  route  sensor  for  a 
terminal  sensor  in  any  of  the  test 
configurations,  but  that  expectation 
was  deemed  worthy  of  some  actual 
testing. 

TEST  ENVIRONMENT.  The  tests  used  as  a 
basis  for  this  report  were  conducted  in 
the  real  world  environment  using  a  test 
aircraft  in  one  of  two  predetermined 
flightpaths  described  below.  Simulated 
fruit  at  levels  previously  used  in 
the  single-site  system  baseline  testing 
program  were  injected  into  the  system 
using  the  ARIES. 

Single  Transponder  Tests.  Testing 
in  the  real  world  was  performed  against 
a  background  of  ATCRBS  targets  of 
opportunity  and  a  DABS  stationary 
transponder  (parrot)  affixed  to  a  tower 
located  at  Mizpah,  New  Jersey,  approxi¬ 
mately  12.5  nmi  southwest  of  the 
Technical  Center  sensor.  The  stationary 
target  has  a  24-bit  hexadecimal  DABS 
address  of  "FAADAB"  and  could  be  set  to 
respond  any  desired  altitude.  Altitudes 
of  5,000  and  10,000  feet  have  been  used 
during  various  phases  of  the  testing. 
A  single  real  aircraft  carried  a 
transponder  with  an  address  of  7FFFFF 
and  flew  one  of  two  predetermined 
patterns : 
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Pattern  A.  The  aircraft  passes 
through  the  cones  of  silence  over  each 
of  the  DABS  sites  for  the  purpose  of 
creating  target  fade  conditions  to  test 
the  network  management  external  track 
data  functions. 

Pattern  B.  The  aircraft  avoids  the 
zenith  cones  and  potential  ATARS 
conflicts  with  the  stationary  Mizpah 
transponder  in  order  to  test  the  uplink 
message  delivery  capability  without 
being  hindered  by  target  fades  and 
competition  from  ATARS  for  use  of  the 
data  link. 

Ideally,  the  aircraft  was  to  have 
maintained  an  altitude  of  5,000  feet 
throughout  the  testing,  but  occasional 
cloud  cover  and  turbulence  necessitated 
deviations  from  this  goal  to  a  maximum 
altitude  of  8,500  feet.  From  the  view¬ 
point  of  network  management,  the  most 
observable  feature  of  the  altitude 
difference  is  the  size  of  the  cones 
of  silence  and,  hence,  the  length  of 
time  that  the  aircraft  is  not  tracked 
on  local  data  as  it  passes  over  the 
sensors.  Because  the  cell  structure  of 
the  coverage  maps  is  also  affected  by 
altitude,  some  displacement  of  the 
point 8  of  primary/secondary  transitions 
would  be  expected. 

Dual  Transponder  Tests.  One 
feature  of  the  stand-alone  network 
management  design  is  the  extension  (up 
to  a  maximum)  of  the  length  of  the  lock 
cycle  in  order  to  avoid  simultaneous 
unlock  of  two  proximate  transponders 
with  consequent  risk  of  garbling.  Two 
tests  were  made  with  two  transponders 
carried  aboard  a  single  test  aircraft. 
These  transponders  were  addressed  as 
7FFFFF  and  555555,  respectively,  with 
the  7FFFFF  transponder  reporting  the 
actual  mode  C  altitude  of  the  aircraft, 
while  the  555555  transponder  was  set 
to  respond  with  a  fixed  altitude  of 
10,000  feet. 

NETWORK  COVERAGE  MAPS.  The  network 
management  coverage  used  by  each  of  the 
sensors  is  defined  by  a  site-specific 


coverage  map,  which  is  expressed  as 
a  collection  of  cells  in  a  polar 
coordinate  system  having  the  antenna  as 
its  origin.  Each  cell  contains  a 
specification  of  the  multiplicity  of 
coverage  desired  by  the  user  and  an 
ordered  list  of  the  neighboring  sensors 
that  are  regarded  as  candidates  for  the 
list  of  "assigned"  sensors;  i.e. ,  those 
being  used  for  redundant  surveillance. 
If  the  user  specifies  the  local  sensor 
to  be  at  the  top  of  the  assigned  sensor 
list  for  a  given  cell,  the  local 
sensor  is  regarded  as  primary  for 
uncontrolled  targets  within  that  cell. 
Such  a  defaulted  assignment  may  be 
overridden  by  an  aircraft  control  state 
message  generated  by  the  controlling  ATC 
facility.  All  primary  assignments  in 
this  report  are  as  dictated  by  the 
coverage  maps,  except  where  noted. 

For  test  purposes,  the  coverage  maps 
were  devised  with  areas  of  overlapping 
primary  assignment.  Multiple  primary 
assignments  are  to  be  expected  in 
areas  where  there  is  overlapping 
primary  coverage  involving  unconnected 
sensors.  These  multiple  assignments  are 
resolved  into  single  assignments  when 
connectivity  between  the  sites  is 
present.  For  test  purposes,  overlapping 
primary  coverage  was  assigned  to  the 
Technical  Center  and  Elwood  sensors  in 
the  vicinity  of  the  Technical  Center. 
Similarly,  overlapping  primary  coverage 
was  assigned  to  the  Clementon  and  Elwood 
sensors  in  the  vicinity  of  Clementon. 
In  the  vicinity  of  Elwood  all  three 
sensors  were  specified  to  have 
overlapping  primary  responsibility. 

DATA  LINK  SCENARIOS.  Three  separate 
scenarios  were  used  for  testing  the 
performance  of  the  data  link  between 
the  DABS  sensors  and  the  test  aircraft 
with  respect  to  dats  link  capacity  and 
message  handling  protocal.  These  are 
named  SI,  S2,  and  S3  and  have  the  char¬ 
acteristics  described  in  the  following 
paragraphs.  These  scenarios  are  sent  by 
the  STC  operating  as  a  simulated  ATC 
facility.  Tactical  uplink  messages  are 
sent  at  the  rate  of  two  messages  to 
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each  DABS  address  every  5  seconds.  This 
race  is  maintained  for  2  minutes,  and 
then  a  1-minute  gap  occurs  allowing  time 
for  any  outstanding  message  transactions 
to  be  completed.  The  message  rate  is 
then  increased  by  one  and  the  above 
sequence  is  repeated  until  a  message 
rate  of  eight  is  concluded.  Each  of 
the  messages  is  a  single  segment, 
normal  priority  tactical  uplink  with  a 
"time-to-expiration"  of  three  scans,  and 
each  contains  a  4-bit  internal  message 
number.  In  each  successive  message  to  a 
given  address  the  message  number  is 
incremented  by  1  until  a  maximum  of  15 
is  reached  and  the  cycle  starts  over. 

1.  Data  link  scenario  SI.  This 

scenario  addresses  all  messages  through 
the  Technical  Center  sensor  to  destina¬ 
tions  of  the  Mizpah  transponder  (FAADAB) 
and  the  test  aircraft  (7FFFFF). 

2.  Data  link  scenario  S2.  Scenario  S2 
is  identical  to  SI  except  that  all 
messages  are  addressed  to  FAADAB  and 
7FFFFF  through  the  Elwood  Sensor. 

3.  Data  link  scenario  S3.  Messages  in 
this  scenario  are  sent  through  all 
three  DABS  sensors.  For  messages  sent 
through  the  Technical  Center  and  Elwood 
sensors,  the  destinations  are  FAADAB, 
7FFFFF,  and  55555.  Since  the  Mizpah 
parrot  is  mounted  too  low  to  be  tracked 
consistently  by  Clementon,  the  desti¬ 
nations  used  for  messages  sent  through 
the  Clementon  sensor  are  7FFFFF  and 
555555  only.  During  the  tests  that  did 
not  involve  555555,  the  DABS  sensor  was 
expected  to  respond  with  message 
rejection  notices  indicating  that  the 
target  was  not  being  tracked  within  the 
surveillance  area. 

TEST  MATRIX.  Tests  were  conducted 
according  to  the  specifications  set 
forth  in  the  test  matrix  shown  in 
table  1.  The  test  matrix  is  organized 
such  that  each  test  is  listed  by  its 
respective  test  number.  Test  data  used 
in  this  report  were  taken  from  tests  13 
through  34  and  48  through  55.  For  each 


test  the  matrix  specifies  date  of  test, 
participating  sensor(s),  connectivity, 
fruit,  data  link  scenario,  and  number  of 
DABS  transponders. 

DATA  COLLECTION. 

TEST  CONDUCT.  At  the  beginning  of  each 
test  all  participating  sensors  underwent 
an  initial  program  load  and  were 
released  into  operation  simultaneously 
by  voice  command  over  the  telephone. 
After  verification  that  all  partici¬ 
pating  sites  were  operational,  the 
nonparticipating  sites  were  declared 
to  be  "failed"  sensors  by  means  of 
messages  sent  from  the  STC.  Data 
extraction  were  initiated  simultaneously 
at  all  the  operating  sensors,  and  data 
link  scenarios  were  started  shortly 
after  the  beginning  of  each  test.  Each 
test  run  was  concluded  with  a  system 
dump  after  completion  of  the  data  link 
activity. 

DATA  RECORDING  TAPES.  Data  were 
collected  on  magnetic  tape  at  each  of 
the  participating  sensor  sites  as  well 
as  at  the  STC. 

System  Test  Console.  The  STC 
monitors  in  real  time  all  communication 
and  surveillance  lines  in  the  DABS  net¬ 
work  and  records  these  data  on  digital 
tape.  The  resulting  time-ordered  merge 
of  the  many  data  streams  is  well-suited 
to  supporting  a  system-level  analysis  of 
DABS  multisite  performance  in  less  than 
a  capacity  environment.  Sensor-to- 
sensor  message  exchanges  (if  any)  and 
sensor-to-ATC  message  traffic  are 
recorded  in  the  order  of  their 
occurrence,  allowing  for  cause-and- 
effect  analysis  of  message  transactions 
occurring  in  multiple  sensor  tests. 

Certain  information,  such  as  the 
contents  of  a  DABS  surveillance  file 
entry,  are  needed  for  data  analysis  in 
the  areas  of  surveillance  processing  and 
network  management.  Normally,  much  of 
this  information  is  maintained  only 
within  the  internal  data  base  of  a 
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TABLE  1.  MULTISITE  NETWORK  MANAGEMENT  TEST  MATRIX 
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sensor  and  is  not  shared  with  other 
sensors  or  with  ATC  facilities.  To  aid 
in  the  analysis  of  multisite  data, 
special  surveillance  file  "snapshot" 
messages,  which  have  a  message  type  code 
of  90  and  which  are  activated  through  a 
site-adaptation  command,  have  been  added 
to  the  system.  These  messages  may  be 
addressed  to  any  external  "facility" 
whose  lines  are  monitored  and  recorded 
by  the  STC.  Because  of  bandwidth  and 
processing  limitations,  only  a  limited 
number  of  DABS  targets  may  be  treated  in 
this  manner.  Other  kinds  of  internal 
data,  such  as  DABS  raw  replies,  are 
never  sent  between  facilities  and 
are,  therefore,  not  available  to  the 
STC. 

Sensor  Data  Extraction.  As  part  of 
the  initial  program  load,  the  sensor  is 
given  a  set  of  data  extraction  commands 
specifying  which  operational  data  are  to 
be  collected  and  written  to  magnetic 
tape.  The  operator  may  override  this 
command  set  by  use  of  cassettes  or 
keyboard  entry.  The  current  testing 
effort  required  that  raw  DABS  replies 
be  collected  to  assist  in  monitoring 
the  behavior  of  the  various  DABS 
transponders  used  and  to  observe  the 
formation  of  DABS  reports  from  their 
component  replies.  The  data  extraction 
function  also  collects  surveillance 
file  information  on  both  DABS  and 
ATCRBS  tracks.  Other  useful  data 
collected  include  a  recording  of  all 
site-adaptat ion  parameters  used  during 
the  test,  and  a  "memory  dump"  at  the  end 
of  the  tape  to  aid  in  determining  the 
exact  state  of  the  global  memory  and 
the  DABS  computers  at  the  instant  the 
test  was  terminated. 


TEST  RESULTS  AND  ANALYSIS 


NETWORK  MANAGEMENT. 

Network  management  data  analysis 
consisted  largely  of  inspecting  system 
data  to  show  that  the  functional 


operating  requirements  were  being  met. 
These  characteristics  and  their  verifi¬ 
cation  are  described  in  this  section. 
For  convenience,  they  are  broken  down 
into  categories  of  "General  Results" 
that  apply  to  all  DABS  configurations, 
"Multisite  Netted  Results"  that  apply  to 
netted  systems  only,  and  "Multisite 
Nonnetted  Results." 

GENERAL  RESULTS.  The  following  results 
were  verified  for  all  tests,  whether 
netted  or  nonnetted: 

1.  Determination  of  sensor  priority 
status.  The  assignment  of  the  local 
DABS  sensor  as  primary  or  secondary, 
with  respect  to  data  communications 
downlinked  from  an  aircraft,  was  made  in 
the  case  of  an  uncontrolled  aircraft 
according  to  information  derived  from 
the  network  coverage  map.  In  the  case 
of  a  controlled  aircraft,  it  was  made  as 
directed  by  the  most  recent  ATC  control 
state  message.  The  correct  setting  of 
the  sensor  priority  status  bit  was 
verified  by  inspection  of  the  surveil¬ 
lance  file  for  each  cell  boundary 
crossing  along  the  flightpath  of  the 
test  aircraft. 

2.  Adjacent  sensor  assignment.  Each 
time  an  aircraft  crossed  a  surveillance 
boundary  (which  is  usually,  but  not 
always,  the  boundary  of  a  cell  in  the 
network  coverage  map)  the  position  of 
the  target  was  used  to  assign  a  set  of 
adjacent  sensors  which,  geographically 
speaking,  were  capable  of  providing 
redundant  surveillance  coverage.  The 
assignments  of  these  sensors,  if  any, 
and  their  connectivity  characteristics 
(connected  or  unconnected)  were  verified 
by  inspection  of  dumps  of  surveillance 
file  information  from  the  STC  recording 
tape. 

MULTISITE  NETTED  RESULTS.  The  following 
results  were  obtained  from  tests 
involving  netted  sensors: 
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K  Track  data  message  protocol.  During 
periods  when  the  aircraft  was  not 


visible  to  the  local  sensor,  data  were 
supplied  upon  request  from  other 
sensors  in  the  net  that  had  the  aircraft 
under  surveillance.  The  exchange  of 
network  management  messages  required 
to  accomplish  the  external  support 
involved  a  track  data  request,  track 
data  messages,  cancel  request,  and 
data  stop  message.  Dumps  of  the  STC 
recording  tape  were  inspected  in  order 
to  verify  that  the  message  sequences 
were  correct.  Tracks  newly  acquired  by 
the  local  sensor  were  shared  with 
adjacent  connected  sensors  through 
spontaneous  issuance  of  track  data 
messages.  Receiving  sensors  which  were 
able  to  track  the  targets  locally  turn 
off  the  incoming  data  by  sending  cancel 
request  messages.  This  sequence  of 
events  was  also  verified  by  inspection 
of  STC  dumps. 

2.  INLIST  and  OUTLIST  entries.  When¬ 
ever  a  sensor  was  supplying  track  data 
to  one  or  more  adjacent  sensors,  the 
recipient(s)  were  identified  in  a 
surveillance  file  entry  known  as  the 
OUTLIST.  A  sensor  receiving  data  from 
one  or  more  sources  stored  the  identity 
of  the  supplier(s)  in  the  INLIST,  along 
with  a  flag  showing  which  stream  of 
incoming  data  was  being  retained  for 
local  use.  Dumps  of  the  STC  recording 
tapes  were  used  to  test  the  management 
of  the  INLIST  and  the  OUTLIST  during 
periods  of  track  data  message  exchange. 
It  was  during  these  tests  that  a  pair  of 
coding  errors  in  the  management  of  the 
INLIST  were  identified.  One  error 
resulted  in  the  failure  to  discard  track 
data  messages  that  arrive  from  any  but 
the  "active"  INLIST  sensor.  The  other 
error  resulted  in  a  failure  to  clear  the 
INLIST  flag  when  the  incoming  track  data 
stream  was  interrupted.  These  errors 
were  such  that  the  "sole-source"  charac¬ 
teristic  of  the  incoming  data  stream  for 
a  given  track  could  not  always  be 
guaranteed . 

3.  Externally  supplied  track  data. 
During  periods  of  prolonged  fade, 
particularly  in  the  cone  of  silence  over 


a  sensor's  antenna,  a  connected  adjacent 
sensor  was  expected  to  supply  sufficient 
surveillance  data  to  permit  the  local 
sensor  to  maintain  tracking  until 
the  target  emerged  from  the  fade  and 
could  once  again  respond  to  local 
interrogations.  Tests  were  performed  on 
networks  of  two  and  three  sensors  in 
varying  states  of  connectivity.  The 
results  showed  that  tracking  was 
maintained  throughout  the  zenith  cone  on 
external  data  supplied  from  connected 
adjacent  sensors.  One  of  the  tests 
discussed  ("Three  Sensors,  One 
Unconnected,"  in  the  Network  Management 
Results  of  Specific  Tests  section), 
presents  some  figures  which  show 
tracking  across  two  of  the  three  zenith 
cones  in  a  test  environment  of  only  one 
connected  adjacent  sensor.  The  presence 
of  only  one  connected  sensor  provides 
certainty  over  the  source  of  the  data, 
showing  that  tracking  through  the  zenith 
cone  can  be  maintained  on  the  remote 
data  provided  by  a  single  sensor. 

4.  Sensor  priority  status  in  the  zenith 
cone .  The  current  system  design 
allows  several  scans  (the  maximum 
expected  could  be  on  the  order  of  20)  to 
occur  between  the  time  an  uncontrolled 
target  fades  in  the  local  zenith 
cone  and  a  neighboring  sensor  has  a 
cell  boundary  crossing  that  would 
trigger  a  primary  handoff  transaction. 
During  this  time  no  sensor  could 
exercise  primary  responsibility  for 
the  target,  notably,  the  readout  of  a 
pilot-originated  downlink  message. 
Creation  of  a  new  "primary  available" 
message  to  trigger  an  earlier  boundary 
crossing  would  help  in  some  cases.  (See 
item  3  of  "Recommendations"  for  "Network 
Management . ") 

MULTISITE  NONNETTED  RESULTS.  The 
following  results  were  observed  for 
tests  involving  nonnetted  sensors: 

1.  Lockout  state  and  lockout  counts. 
In  a  multisensor  environment  containing 
one  or  more  unconnected  adjacent 
sensors  providing  redundant  surveillance 
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coverage,  the  state  of  lockout  to 
All-Calls  must  be  changed  periodically 
to  "unlocked"  to  allow  for  target 
acquisition  by  adjacent  sensors.  The 
locked  state  was  maintained  for  a 
site-adaptable  number  of  scans  and  was 
followed  for  another  number  of  scans 
by  an  unlock  period  in  which  the 
transponder  was  allowed  to  time  out 
and  begin  responding  to  All-Calls. 
This  mode  of  operation  is  known  as 
"intermittent  lockout."  The  length 
of  the  lock  and  unlock  sequences,  as 
well  as  the  actual  lockout  bit  config¬ 
uration,  was  observed  in  dumps  of  the 
surveillance  file  and  in  the  output  of 
one  of  the  Honeywell  computer  programs 
(item  5  of  appendix  B) .  These  sequence 
lengths  were  seen  to  correspond  to  those 
specified  by  site  adaptation. 

2.  System-wide  periods  of  transponder 
unlock.  Verification  that  the  lockout 
state  and  -lockout  counts  were  correctly 
maintained  on  an  individual  sensor  basis 
(item  1)  was  not  sufficient  to  verify 
the  performance  of  network  management  in 
a  multisensor  nonnetted  environment. 
The  system  must  function  globally  in 
such  a  way  as  to  ensure  that  the  periods 
of  unlock  are  synchronized,  enabling  ail 
sensors  to  receive  All-Call  replies. 

Tests  were  conducted  with  the 
three  sensors  in  various  states  of 
connectivity,  from  totally  connected  to 
totally  unconnected.  In  the  case  of 
total  connectivity,  no  periods  of  unlock 
were  needed  or  expected.  In  all  other 
cases,  such  periods  were  required  during 
flights  in  regions  of  overlap.  The 
verification  that  transponder  unlock 
periods  became  synchronized  across  the 
system  was  made  using  plots  of  the 
All-Call  reply  sequences,  like  those 
presented  in  the  Lockout  Management 
portion  of  the  Network  Management 
"Results  of  Specific  Tests"  section 
below. 

RESULTS  OF  SPECIFIC  TESTS.  Although 
tests  were  performed  using  the  DABS 
sensors  in  all  possible  combinations  and 


in  all  possible  states  of  connectivity, 
only  three  cases  have  been  selected  for 
a  detailed  discussion  in  this  report. 
These  three  cases  involve  all  three  DABS 
sensors  and  the  connectivity  states 
fully  connected  (each  sensor  communi¬ 
cating  with  the  other  two),  fully 
unconnected  (no  sensor  communicating 
with  any  other),  and  the  case  of  two 
connected  to  each  other  with  the  third 
not  connected  to  either  of  the  first 
two.  The  results  that  have  been  omitted 
provide  no  new  information  beyond  the 
cases  discussed.  Three  plots,  one 
showing  the  live  DABS  track  as  seen  by 
each  sensor,  are  presented  for  each 
of  the  three  cases.  The  first  plot  in 
each  set  shows  the  track  as  seen  by  the 
Technical  Center,  the  second  shows  the 
same  track  as  seen  by  Elwood,  and  the 
third  plot  represents  the  same  track  in 
the  Clementon  sensor.  Special  symbols 
are  used  to  differentiate  among  the 
possible  track  states  within  a  given 
sensor:  a  chevron  represents  a  local 
track  when  the  sensor  is  primary,  a  dot 
represents  a  local  track  when  the  sensor 
is  secondary,  a  slash  is  used  to  show 
that  the  track  is  being  maintained  on 
external  data,  and  a  box  indicates  a 
scan  on  which  the  track  is  being 
coasted. 

Three  Sensors,  All  Connected. 
These  results  are  the  output  of  test 
number  13  (run  3)  of  the  test  matrix. 
The  flightpath  begins  southeast  of  the 
Technical  Center  sensor  and  traverses  in 
succession  all  three  sensor's  zenith 
cones.  Figure  2,  depicting  the  track  as 
seen  by  the  Technical  Center,  shows  that 
the  Technical  Center  sensor  is  primary 
for  downlink  communications  (indicated 
by  the  chevron  symbol  on  the  plot).  The 
other  sensors,  Elwood  (figure  3)  and 
Clementon  (figure  4),  are  secondary 
(indicated  by  the  dot  symbol  on  their 
plots)  showing  that  coordination 
between  the  sensors  has  occurred  and  the 
network  has  agreed  upon  only  one  primary 
sensor.  (As  will  be  shown  in  the  next 
section,  lack  of  such  coordination 
results  in  multiple  primary  sensors.) 
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FIGURE 


TECHNICAL  CENTER  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  CONNECTED 

ORBS  SENSOR  ELMOOO 


FIGURE  3 


ELWOOD  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  CONNECTED 


(MBS  SENSOR  CLEMENTON 


Figure  2  shows  that  the  Technical  Center 
sensor  remains  primary  with  the  track  on 
local  data  until  it  enters  the  zenith 
cone,  at  which  time  the  track  is  updated 
using  external  data  (indicated  by  the 
slash  symbol).  An  enlarged  plot  of  the 
Technical  Center  zenith  cone  area  is 
given  in  figure  5.  This  plot  shows  an 
unexpected  primary  report  within  the 
zenith  cone.  The  jitter  observed  in 
the  external  data  is  attributed  to 
coordinate  conversion  errors  that  are 
generated  near  the  center  of  the  zenith 
cone  (origin  of  the  coordinate  system). 

When  the  target  is  once  again  seen 
by  the  Technical  Center  sensor  and  is 
being  tracked  locally,  it  is  apparent 
from  the  symbol  (dot)  in  both  figures  2 
and  5  that  a  transition  from  primary  to 
secondary  sensor  status  occurred  while 
the  target  was  being  tracked  on  remote 
data.  Inspection  of  the  track  plot  from 
the  Elwood  sensor  (figure  3)  shows  that 
while  the  track  was  in  the  fade  condi¬ 
tion  at  the  Technical  Center,  Elwood 
seized  primary  status,  which  it  kept 
until  the  fade  occurred  in  Elwood's 


zenith  cone  and  the  Technical  Center  was 
able  to  seize  back  the  primary  status. 
When  the  aircraft  departed  from  the 
region  in  which  the  Technical  Center  was 
permitted  to  be  primary  (about  one-third 
of  the  distance  between  Elwood  and 
Clementon),  primary  status  was  handed 
off  to  the  Elwood  sensor  (figure  3). 
This  figure  also  shows  that  in  the 
Elwood  zenith  cone  the  track  was 
maintained  on  externally  supplied  data. 
An  enlarged  view  of  the  Elwood  zenith 
cone  is  given  in  figure  6.  The  remote 
data  shown  in  this  figure,  while 
adequate  to  maintain  the  aircraft  in 
track  on  all  but  two  scans  (the  coasts 
are  shown  by  the  box  symbols),  was  not 
as  smooth  as  that  shown  in  the  similar 
plot  for  the  Technical  Center.  Coasts 
which  appear  in  these  plots  are 
indicative  of  poor  predictions  that  take 
place  when  the  target  is  close  to  the 
origin  of  coordinates.  The  "sawtooth" 
appearance  of  the  remote  data  in  the 
Elwood  zenith  cone  is  attributed  to  the 
software  coding  errors  which  allowed  a 
mixture  of  remote  data  from  the  other 
two  sensors  to  be  used  for  track  update. 
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FIGURE  5.  TECHNICAL  CENTER  ZENITH  CONE  SURVEILLANCE  PLOT, 
THREE  SENSORS,  ALL  CONNECTED 
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ELWOOD  ZENITH  CONE  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  CONNECTED 


Figure  4  shows  Chat  Che  Clementon 
sensor  cracked  Che  aircrafe  solidly  up 
Co  Che  poinC  of  enCry  inCo  Che  ClemenCon 
zenich  cone  (see  deCail  in  figure  7), 
excepC  for  one  coast  near  Che  very 
beginning  of  Che  Crack,  aCCribuCed  Co 
shielding  of  Che  aircraft's  antenna 
during  the  turn.  As  was  expected,  the 
ClemenCon  sensor  remained  secondary 
until  the  aircraft  departed  from  the 
Glwood  primary  coverage  area  and 
received  a  handoff  of  primary  status 
from  Glwood.  The  Glwood  plot  (figure  3) 
shows  the  transition  of  Glwood  from 
primary  to  secondary  at  the  same  point 
as  the  Clementon  plot  (figure  4)  shows 
Clementon' s  transition  from  secondary  to 
primary. 

During  some  connected  tests, 
notably  test  14  (run  1)  and  test  16 
(run  2),  a  track  was  maintained  on 
external  data  for  a  considerable  time 
following  its  exit  from  the  Clementon 
zenith  cone.  When  local  tracking  was 
finally  resumed  it  appeared  normal. 
In  both  these  cases,  an  incorrect 
time-of-day  value  was  supplied  by 
the  Glwood  sensor  as  part  of  the 
remote  track  data.  The  resulting 
prediction  error  caused  the  Clementon 
sensor  to  miss  the  track  with  local 
interrogations.  The  time-of-day  problem 
resulted  from  the  failure  of  the  clock 
to  lock  onto  the  WWVB  signal  and  is  a 
phenomenon  associated  with  poor  signal 
propagation  in  certain  locales  and  at 
certain  seasons  of  the  year.  A  proposal 
to  upgrade  the  clocks  is  currently  under 
study. 

Three  Sensors,  All  Unconnected. 
These  results  were  obtained  from  test  21 
(run  2)  of  the  test  matrix.  The  flight- 
path  starts  a  few  miles  west  of  the 
Technical  Center  in  a  coverage  map 
region  in  which  both  the  Technical 
Center  and  Glwood  are  primary.  Since 
there  is  no  communication  between  the 
sensors,  assignment  of  a  single  primary 
sensor  cannot  be  resolved  and  the 
condition  of  dual  primary  exists.  (See 
figure  8  for  the  Technical  Center  plot 
and  figure  9  for  the  Glwood  plot.)  The 
Clementon  sensor  is  secondary  in  this 


region  as  is  seen  from  the  Clementon 
plot  (figure  10).  As  the  aircraft 
approaches  the  180°  radial  from  the 
Technical  Center,  it  departs  the  region 
in  which  Glwood  has  any  responsibility 
for  primary  coverage  (figure  9  shows  the 
transition  from  primary  to  secondary) 
and  then,  as  the  aircraft  turns  inbound, 
the  transition  back  from  secondary  to 
primary  occurs. 

On  the  Technical  Center  plot 
(figure  8)  the  track  coasts  to  a  drop 
within  the  Technical  Center's  zenith 
cone  as  the  lack  of  sensor-to-sensor 
connectivity  precludes  any  receipt  of 
remote  data  to  be  used  for  external 
tracking.  After  emergence  from  the  cone 
of  silence  the  track  is  reacquired  on 
All-Call  by  the  Technical  Center  showing 
that  the  transponder  is  unlocked. 
Figure  11  shows  the  enlargement  of  the 
zenith  cone  area  for  the  Technical 
Center  sensor.  Figures  12  and  13  show 
the  Glwood  and  Clementon  zenith  cones, 
respectively.  Plots  of  just  the 
All-Call  replies  received  by  each  of  the 
sensors  during  this  test  are  discussed 
in  the  "Lockout  Management"  section. 
Note  that  the  Glwood  and  Clementon 
tracks  (figures  9  and  10)  are,  as  would 
be  expected,  continuous  through  the 
Technical  Center's  zenith  cone. 

The  Glwood  track  (figure  9)  remains 
primary  for  the  rest  of  the  test  and  is 
continuous  throughout,  except  for  the 
expected  coasts  and  drop  in  the  Glwood 
zenith  cone. 

Figure  10  shows  that  the  track, 
as  seen  by  the  Clementon  sensor,  is 
continuous,  except  for  the  expected 
coast  and  drop  in  the  Clementon  zenith 
cone.  About  midway  between  the 
Technical  Center  and  Glwood  the  aircraft 
enters  the  region  in  which  Clementon  is 
primary.  From  this  point  until  the 
point  in  figure  8  where  the  Technical 
Center  transitions  from  primary  to 
secondary,  a  condition  of  triple  primary 
exists  in  which  all  three  sensors  in 
the  unconnected  state  are  entitled 
to  receive  pilot  initiated  downlink 
communications  from  the  aircraft. 
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FIGURE  7.  CLEMENTON  ZENITH  CONE  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  CONNECTED 
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FIGURE  8.  TECHNICAL  CENTER  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 
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FIGURE  9.  ELWOOD  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 
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FIGURE  10,  CLEMENTON  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 


TECHNICAL  CENTER  ZENITH  CONE 


M-*-n 

FIGURE  11.  TECHNICAL  CENTER  ZENITH  CONE  SURVEILLANCE  PLOT, 
THREE  SENSORS,  ALL  UNCONNECTED 


FIGURE  12.  ELWOOD  ZENITH  CONE  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 
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FIGURE  13.  CLEMENTON  ZENITH  CONE  SURVEILLANCE  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 


Three  Sensors,  One  Unconnected. 
Test  25  (run  2)  from  the  test  matrix  is 
discussed  here  to  show  the  behavior 
of  the  DABS  system  when  two  sensors 
are  connected  to  each  other  and  one 
sensor  (in  this  case,  Clementon)  is  not 
connected  to  either  of  the  others.  In 
such  a  configuration,  the  behavior  of 
the  unconnected  sensor  should  appear 
exactly  as  it  did  in  the  previous  case 
in  which  all  sensors  were  unconnected. 
The  pair  that  are  connected  (Technical 
Center  and  Elwood)  should  behave  exactly 
as  they  did  in  the  case  for  all  sensors 
connected,  with  the  exception  that 
whichever  sensor  of  the  pair  has 
primary  responsibility  will  engage  in 
intermittent  lockout  rather  than  full 
lockout.  The  configuration  in  which 
Elwood  (the  en  route  sensor)  was  the 
unconnected  sensor  was  also  tested 
with  no  appreciable  difference  in  the 
results. 

Figure  14  shows  the  track  as  seen 
at  the  Technical  Center.  It  starts 


southeast  of  the  Technical  Center 
with  primary  status  and,  as  in  previous 
cases,  moves  into  the  zenith  cone 
where  it  is  tracked  on  external  data 
from  Elwood.  The  enlargement  of  the 
Technical  Center  zenith  cone  shown  in 
figure  15  shows  that  the  external  track 
was  well  behaved  except  for  two  coasts 
that  are  attributed  to  prediction  errors 
close  to  the  origin  of  coordinates. 
When  local  tracking  was  resumed,  the 
sensor  priority  status  was  secondary, 
indicating  that  a  primary  coordination 
transaction  had  taken  place  during  the 
fade.  A  glance  at  the  corresponding 
Elwood  plot  (figure  16)  will  verify  that 
Elwood,  as  expected,  assumed  primary 
status  when  the  track  was  within  the 
Technical  Center's  zenith  cone  and 
retained  that  status  until  the  fade 
within  its  own  zenith  cone.  Figure  17 
is  an  enlargement  of  the  Elwood 
zenith  cone.  The  four  coasts  are  also 
attributed  to  prediction  errors  close  to 
the  origin  of  coordinates. 
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FIGURE  14.  TECHNICAL  CENTER  SURVEILLANCE  PLOT, 
THREE  SENSORS,  CLEMENTON  UNCONNECTED 
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FIGURE  16.  ELWOOD  SURVEILLANCE  PLOT,  THREE  SENSORS,  CLEMENTON  UNCONNECTED 
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FIGURE  17.  ELWOOD  ZENITH  CONE  SURVEILLANCE  PLOT, 
THREE  SENSORS,  CLEMENTON  UNCONNECTED 
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When  Che  aircraft  departed  from 
the  Technical  Center's  primary  area 
northwest  of  Elwood  a  coordination  took 
place  that  left  the  Technical  Center 
secondary  and  Elwood  primary  for  the 
remainder  of  the  test. 

The  Clementon  sensor  (figure  18) 
was  unconnected  during  the  entire  run 
so  that  its  determination  of  status  was 
made  with  reference  only  to  its  own 
network  coverage  map.  It  became  primary 
at  a  point  between  the  Technical  Center 
and  Elwood  (where  it  shared  dual  primary 
with  Elwood)  and  remained  primary  for 
the  remainder  of  the  test,  with  the 
exception  of  a  short  sequence  on  the 
southeast  bound  leg.  This  sequence  will 
be  discussed  in  the  next  section 
(see  "Control  State  Message"). 

The  enlargement  of  the  Clementon 
zenith  cone  (figure  19)  shows  clearly 
that  the  track  coasted  to  a  drop  since 
it  could  not  be  supported  by  remote 
data.  It  was  reinitiated  with  a  new 
track  number  after  receipt  of  two  local 
reports,  and  remained  secondary  (dot 
symbols)  until  it  was  established  on 
roll-call. 

Control  State  Message.  Figure  18, 
discussed  in  the  previous  section, 
contains  an  illustration  of  the  effect 
of  sending  a  control  state  message.  The 
message  was  sent  to  the  Clementon  sensor 
from  the  STC  in  its  role  as  a  simulated 
ATC  facility,  and  instructed  the  sensor 
to  make  the  track  controlled  and  set  the 
sensor  priority  status  to  secondary. 
After  the  status  transition  was 
observed,  another  message  was  sent 
restoring  the  track  to  its  original 
uncontrolled  state.  The  Clementon 
sensor  then  made  the  determination  of 
primary  status  based  on  the  contents  of 
the  network  coverage  map. 

Lockout  Management .  In  surveil¬ 
lance  areas  covered  by  multiple  sensors 
that  are  not  connected  to  each  other, 
the  DABS  system  invokes  a  technique 
called  "intermittent  lockout"  in  which 
DABS  transponders  are  allowed  to  be 
unlocked  to  All-Calls  for  a  specified 
number  of  scans.  The  presence  of  the 


All-Call  replies  allows  an  unconnected 
sensor  that  may  have  dropped  a  track 
(as  happens  in  its  own  zenith  cone) 
to  reacquire  it.  The  fact  that  the 
tracks  were  reacquired  by  each 
unconnected  sensor  upon  departure  from 
the  cone  of  silence  is  an  indication 
that  the  transponder  is  undergoing 
synchronized  intermittent  unlock.  A 
more  extensive  data  analysis  was 
performed  by  inspecting  the  surveillance 
file  entries  at  each  sensor  and 
verifying  that  the  lock  counts,  the 
unlock  counts,  and  the  lockout  bits 
were  being  set  correctly.  A  visual 
indication  of  the  synchronous  unlock 
are  available  in  figures  20  through  22, 
which  show  All-Call  replies  received 
at  the  Technical  Center,  Elwood,  and 
Clementon  sensors,  respectively.  The 
very  fact  that  All-Call  replies  were 
received  is  proof  that  periods  of  trans¬ 
ponder  unlock  occured.  The  center  of 
the  plot  in  figure  22  shows  an  unexpec¬ 
tedly  large  sprinkling  of  All-Call 
reflections.  The  Clementon  sensor 
does  not  have  a  reflector  file.  This 
phenomenon  should  be  investigated  after 
a  reflector  file  has  been  installed. 

Lock/Unlock  Extension.  To  prevent 
garbling  of  All-Call  replies  returned 
from  targets  that  are  physically  close 
to  each  other,  the  engineering  require¬ 
ment  ( FAA-ER-240-26 )  requires  the 
network  management  function  to  perform  a 
proximity  test  on  aircraft  in  the 
vicinity  of  a  transponder  that  is  about 
to  be  unlocked.  If  a  nearby  transponder 
is  also  about  to  be  unlocked,  the  lock 
period  for  one  of  the  transponders  is 
extended  (up  to  a  site-adaptable  maximum 
number  of  track  updates)  in  an  attempt 
to  avoid  the  garble  that  might  result 
from  a  synchronous  unlock.  Waiting  the 
extra  time  gives  the  targets  time  to 
move  away  from  each  other  or  to  allow 
the  unlocking  transponder  to  complete 
its  unlock  cycle  and  begin  a  new  lock 
cycle  before  the  other  unit  actually 
becomes  unlocked.  In  addition,  the 
software  is  implemented  such  that  the 
unlock  period  will  be  extended  instead 
of  the  lock  period  if  the  synchronous 
unlock  cycle  occurs  first. 
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FIGURE  18.  CLEMENTON  SURVEILLANCE  PLOT,  THREE  SENSORS,  CLEMENTON  UNCONNECTED 
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FIGURE  19.  CLEMENTON  ZENITH  CONE  SURVEILLANCE  PLOT, 
THREE  SENSORS,  CLEMENTON  UNCONNECTED 
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FIGURE  20.  TECHNICAL  CENTER  ALL-CALL  REPLY  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 
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FIGURE  21.  ELWOOD  ALL-CALL  REPLY  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 
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FIGURE  22.  CLEMENTON  ALL-CALL  REPLY  PLOT,  THREE  SENSORS,  ALL  UNCONNECTED 


The  extended  lock/unlock  feature 
was  tested  by  mounting  two  DABS  trans¬ 
ponders  in  the  same  aircraft,  one  (DABS 
address  7FFFFF)  connected  to  the  lower 
antenna  system,  and  one  (DABS  address 
555555)  connected  to  the  upper  antenna 
system.  The  aircraft  was  then  flown 
in  a  two-sensor  unconnected  config¬ 
uration  in  test  46  (run  1)  of  the  test 
matrix.  The  test  was  conducted  in  the 
following  way:  with  the  aircraft  in  a 
surveillance  area  in  which  the  Technical 
Center  was  primary  and  Elwood  was 
secondary,  the  7FFFFF  transponder 
was  turned  on  first  and  acquired  on 
roll-call  before  the  555555  transponder 
was  activated.  Both  of  the  transponders 
were  being  roll-called  by  both  sensors, 
but  the  stagger  introduced  in  turning 
them  on  for  acquisition  was  then 
propagated  into  the  lock  and  unlock 
sequences.  Lock/unlock  extension  does 
not  occur  unless  the  transponders  are 
synchronized  in  their  lock/unlock 
cycles.  The  condition  of  simultaneous 


unlock  occurred  at  Elwood  as  soon  as  the 
aircraft  crossed  the  boundary  into 
Elwood's  primary  zone.  When  the 
time  came  for  the  lock  cycle  to  begin 
(unlock  count  of  eight),  the  Elwood 
sensor  locked  the  7FFFFF  transponder  and 
set  the  lock  count  to  one,  while  the 
555555  transponder  remained  unlocked  for 
an  additional  two  scans  before  starting 
its  lock  cycle.  The  stagger  introduced 
in  this  manner  remained  throughout  the 
region  in  which  Elwood  was  required 
to  perform  the  intermittent  unlock 
operation. 

Duplicate  DABS  Addresses.  Although 
the  DABS  system  is  based  on  the  concept 
that  duplicate  addresses  for  aircraft 
are  not  supposed  to  exist  in  the  real 
world,  there  is  a  provision  for  handling 
such  an  event.  It  consists  of  removing 
both  aircraft  track  records  and  reports 
from  the  mainstream  of  the  system, 
placing  them  in  a  holding  area  (the 
duplicate  address  alert  table),  and 
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sending  messages  Co  other  sensors  and  Co  processing  also  was  observed  in  cases 

ATC  facilities  alerting  them  to  the  where  no  concerted  effort  was  made  to 

existence  of  the  condition.  These  force  it.  These  cases  were  always 

messages  contain  position  data  which  observed  during  testing  configurations 

permit  ATC  to  maintain  surveillance.  in  which  Clementon  was  an  unconnected 

sensor  and  arose  from  the  fact 
The  handling  of  duplicate  addresses  that  All-Call  reflections  were  being 

has  been  observed  on  several  occasions.  experienced  by  a  sensor  with  an  empty 

In  one  case  the  aircraft  was  instructed  reflector  file.  The  sensor  was  unable 

to  change  the  code  of  its  transponder  to  discriminate  between  a  reflection 

to  be  the  same  as  the  stationary  target  and  a  duplicate  address  and  correctly 

at  Mizpah.  Both  targets  disappeared  treated  the  situation  as  if  a  duplicate 

from  the  display  screen  and  track  alert  address  existed.  Once  the  aircraft  had 

messages  were  sent  to  all  connected  passed  beyond  the  influence  of  the 

sensors  indicating  the  presence  of  an  reflector,  its  track  was  reacquired 

entry  in  the  duplicate  address  alert  normally.  One  such  test  was  test  18  for 

table.  Any  sensor  receiving  such  a  which  the  Clementon  track  is  shown  in 

track  alert  message  is  required  to  figure  23.  The  gap  in  the  track  just 

remove  the  track  from  its  surveillance  east  of  the  Clementon  zenith  cone 

file  if  it  has  not  already  perceived  the  represents  the  period  during  which 

duplicate  address  condition  through  its  tracking  was  suspended  and  alert 

own  interrogat ion/response  processing.  messages  were  sent.  This  event  also 

Correct  response  to  the  receipt  of  track  resulted,  understandably,  in  a  reduced 

alert  messages  was  observed  during  the  blip/scan  ratio  (BSR)  for  the  aircraft 


test.  When  the  aircraft  changed  its 
code  back  to  the  original  value,  both 
tracks  (the  aircraft  and  the  parrot) 
were  reacquired.  Duplicate  address 


during  this  test,  as  discussed  in  the 
"Surveillance  Processing"  section  of 
this  report. 
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FIGURE  23.  CLEMENTON  SURVEILLANCE  PLOT,  DUPLICATE  ADDRESS  ALERT 
ARISING  FROM  ALL-CALL  REFLECTION 
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SURVEILLANCE  PROCESSING. 


Special  Mode.  When  fewer  than 
three  sensors  were  used  in  a  multisite 
te^t,  sensor  failure  messages  were  sent 
i o  the  remaining  sensor(s)  from  the  STC 
'■daring  all  nonoperating  sensors  to  be 
in  the  "failed"  state.  The  resulting 
configuration  forced  the  operating 
sensors  into  the  "special  mode"  of 
reading  the  network  coverage  map, 
namely,  to  omit  the  failed  sensor(s) 
when  building  the  list  of  adjacent 

assigned  sensors,  and  to  rebuild  that 
list  immediately  upon  detection  of  the 
failure  state.  The  intent  of  the 
one-bit  target  special  mode  flag  in 
specification  FAA-ER-240-26  seems  to 
have  been  to  flag  the  fact  that  the 

special  mode  was  in  effect  at  the 

time  network  management  made  its 

determination  of  the  assigned  sensor 
list.  Un fortunate ly ,  there  are  many 
special  modes:  one  in  which  sensor  A  has 
failed,  one  in  which  sensor  B  has 
failed,  and  one  in  which  both  have 
failed.  A  single  bit  target  special 
mode  flag  is  incapable  of  discriminating 
between  these  failure  states  in  order  to 
determine  whether  one  failure  state  has 
been  replaced  by  another.  (Consider, 
for  example,  the  case  in  which  operation 
begins  with  two  adjacent  sensors  failed 
and  one  subsequent  lv  recovers.  The 
target  special  mode  flag  is  set  in  both 
cases.)  Recause  of  this  ambiguity,  the 
additional  processing  required  for  the 
onset  of  special  mode  is  undertaken  on 
every  scan  during  the  existence  of  any 
failure  state.  While  not  serious  in 
conditions  of  light  track  loads,  there 
is  concern  that  this  situation  may 
interfere  with  capacity  testing. 
Another  concern  exists  with  regard  to 
the  current  implementation's  use  of  the 
special  mode  flag  to  indicate  failure 
not  only  of  a  sensor,  but  also  of 
a  commun icat ions  link  to  a  sensor. 
It  would  be  desirable  to  separate  the 
logic  used  to  process  sensor  failure 
from  that  used  to  process  communications 
failure  by  defining  a  new  flag,  like  the 
special  mode  flag,  that  would  refer  to 
commun i cat  ions  failures  only. 


The  surveillance  performance  of  the  DABS 
equipped  test  aircraft  is  presented 
in  table  2  which  lists  the  BSR  for  each 
of  the  sensors  and  the  sample  size  used 
to  obtain  it.  The  assumptions  used  in 
calculating  the  BSR  are  discussed  in  the 
"Surveillance  Processing  Data  Reduction" 
section  of  appendix  C.  In  addition, 
an  "ATC  BSR"  is  given  which  is  defined 
as  the  number  of  scans  the  ATC  facility 
received  a  report  from  at  least  one 
site,  divided  by  the  number  of  scans 
over  which  the  measurement  was  made, 
with  the  result  expressed  as  a 
percentage.  It  is  a  measure  of  the 
continuity  of  the  surveillance  infor¬ 
mation  received  by  an  ATC  facility  when 
the  output  of  multiple  sensors  can  be 
used  to  "fill-in"  for  reports  missing 
from  any  given  sensor.  As  can  be  seen 
from  the  table,  the  average  BSR  for 
each  of  the  sites  is  above  99  percent, 
as  is  the  ATC  BSR  value.  The  BSR  for  an 
individual  site  excluded  that  portion  of 
the  track  that  was  within  the  zenith 
cone.  Had  the  zenith  cone  data  been 
included,  the  BSR  value  would  have  been 
lower  since  most  of  the  flights  did 
penetrate  the  cone  of  silence.  The 
lowest  BSR  in  the  table  was  95.2  percent 
for  test  18  at  Clementon,  which  resulted 
from  an  All-Call  reflection  that  caused 
the  sensor  to  drop  the  track  for  several 
scans  as  a  consequence  of  duplicate  DABS 
address  processing.  (See  "Network 
Management"  portion  of  this  section.) 
As  can  be  determined  from  tables  1 
and  2,  the  connectivity  of  the  sensors 
(or  lack  of  it)  has  no  observable 
effect  on  the  BSR  values.  The  results 
from  these  multisite  tests  compared 
favorably  with  the  results  presented  in 
the  "DABS  Baseline  Test  and  Evaluation" 
report  (FAA-RD-80-36)  for  which  the 
sensor  was  operated  in  a  single-site 
mode  with  release  6.3  of  the  DABS 
mission  software.  In  the  ARIES  simu¬ 
lation  verification  section  of  that 
report,  two  flight  tests  were  discussed 
in  which  a  similar  measurement  involving 


TABLE  2. 


MULTISITE  SURVEILLANCE  RESULTS 


Data  Filter:  Range  4-59  nmi;  Azimuth  All  AZ  Except  120-145 
At  Tech  Center  (Hangar  Reflections) 

Elevation:  All  Elevation  Angles;  Test  Aircraft  Only  (7FFFFF) 


Sample  Size 

Blip/Scan 

Ratio 

Test 

Tech 

Tech 

No. 

Date 

Center 

Elwood 

Clementon 

Center 

Elwood 

Clementon 

ATC 

13 

4/2/80 

208 

261 

217 

99.5 

100. 

99.5 

100. 

24 

4/2/80 

259 

249 

177 

100. 

100. 

98.9 

100. 

15 

4/7/80 

258 

184 

123 

100. 

100. 

99.2 

100. 

18 

4/7/80 

279 

275 

1681 

100. 

100. 

95.2 

100. 

14 

4/7/80 

216 

224 

189 

100. 

100. 

100. 

100. 

26 

4/16/80 

244 

277 

99.6 

99.3 

99. 

27 

4/16/80 

258 

262 

100. 

98.5 

100. 

19 

4/18/80 

265 

190 

193 

100. 

100. 

99.5 

100. 

20 

4/18/80 

269 

185 

197 

100. 

100. 

100. 

100. 

23 

4/18/80 

262 

N.A. 

200 

98.5 

N.A. 

100. 

100. 

30 

4/21/80 

236 

100. 

100. 

34 

4/21/80 

249 

208 

216 

98.8 

100. 

98.6 

98. 

28 

4/22/80 

287 

240 

100. 

100. 

100. 

29 

4/22/80 

258 

213 

100. 

100. 

100. 

32 

4/22/80 

1262 

100. 

100. 

31 

4/22/80 

266 

1291 

99.6 

99. 

25 

4/30/80 

263 

264 

100. 

100. 

100. 

100. 

16 

5/1/80 

225 

252 

242 

100. 

100. 

100. 

100. 

21 

5/1/80 

261 

176 

285 

100. 

100. 

100. 

100. 

33 

5/1/80 

N.A. 

N.A. 

N.A. 

41 

5/5/80 

272 

301 

100. 

100. 

100. 

42 

5/5/80 

267 

1 1 6 1 

296 

100. 

100. 

100. 

46 

5/15/80 

266 

100. 

100. 

100. 

17 

5/15/80 

257 

142 

232 

100. 

100. 

99.6 

100. 

52 

6/12/80 

234 

N.A. 

100. 

N.A. 

100. 

54 

6/12/80 

225 

100. 

100. 

48 

6/20/80 

288 

1121 

283 

100. 

100. 

100. 

100. 

49 

6/20/80 

280 

N.A. 

286 

100. 

N.A. 

100. 

100. 

50 

6/20/80 

270 

271 

301 

100. 

100. 

100. 

100. 

51 

6/30/80 

280 

284 

100. 

100. 

100. 

53 

7/7/80 

280 

100. 

100. 

55 

7/7/80 

206 

240 

297 

100. 

99.6 

100. 

100. 

Total: 

Avg: 

7188 

4357 

5231 

99.8 

99.9 

99.5 

99. 

Grand  Total:  16776 

Grand  Avg:  99.7 

N.A.  *  Read  error  at  beginning  of  tape 

1  *  Read  error  in  the  middle  of  tape 

2  *  Data  extraction  problem 


a  live  DABS  transponder  yielded  a  value 
of  100  percent.  Comparison  of  the 
single  site  results  with  those  obtained 
i  i  the  multisite  environment  show  that 
the  surveillance  performance  of  a 
network  of  DABS  engineering  model 
<  >nsors  is  excellent. 

In  all  tests,  both  baseline  and 
multisite,  the  reliability  figures 
for  the  DABS  identifier  (ID)  and  the 
altitude  reliability  for  DABS  roll-call 
reports  were  100  percent. 


R  =  Number  of  tactical  uplinks 
rejected  where  rejected  refers  to 
a  message  rejection/delay  notice 
specifying  rejection. 

D  =  Number  of  tactical  uplinks 
delayed  where  delayed  refers  to 
a  message  re ject ion/delay  notice 
specifying  delay. 

N  =  Number  of  tactical  uplinks 
received  at  the  sensor  from  the 
ATC. 


The  number  of  DABS  interrogations 
per  scan  was  calculated  manually  for 
five  of  the  multisite  tests  (test 
numbers  15,  20,  28,  29,  and  34).  The 
data  were  collected  when  the  test 
aircraft  ranged  from  15  to  25  nmi  from 
the  DABS  sensor.  Under  these  conditions 
the  number  of  interrogations  per  scan 
was  calculated  to  be  1.04.  The 
corresponding  measurement  in  the  "DABS 
Baseline  Test  and  Evaluation"  report  had 
a  value  of  1.17.  The  difference  between 
these  values  resulted  because  of 
including  in  the  baseline  calculation 
aircraft  closer  than  15  nmi  from  the 
site.  A  recomputation  of  the  baseline 
1.17  value,  excluding  the  close-in 
reports,  yielded  a  value  of  1.06,  which 
is  in  very  close  agreement. 


DATA  LINK  MESSAGE  PROCESSING. 


The  results  of  data  link  testing  are 
shown  as  plots.  Thirteen  different 
plots  are  used  in  presenting  the  data. 
The  variables  defined  are  totals  for 
each  message  rate  (see  "Data  Link 
Scenarios"  section,  page  9). 


L  =  Number  of  tactical  uplinks 
delivered  where  delivered  refers 
to  a  message  delivery  notice 
specifying  successful  delivery. 


Number  of  tactical  uplinks 
expired  where  expired  refers  to 
a  message  delivery  notice 
specifying  expiration. 


M(i)  =  Number  of  tactical  uplinks 
delivered  in  i  time  units, 


where  i  =  0,1, 2. ..,7 


and  one  time  unit  is  five 
seconds . 


Note:  M ( i )  is  a  discrete  distribution 
and  groups  the  messages  delivered  into 
5-second  intervals.  The  exact  time 
difference  could  not  be  measured,  only 
the  5-second  interval  in  which  the 
delivery  notice  occured  (referenced  to 
the  time  of  receipt  of  the  message  at 
the  sensor  from  the  ATC). 


The  plots  represent  the  following 
statistical  data: 


1.  Messages  delayed  (percent)  as  a 
function  of  incoming  message  rate: 


Pd 


100  x 


N 


2.  Completed  transactions  (percent)  as 
a  function  of  incoming  message  rate: 


Pc  =  100  x 


(L+E+R) 


N 


3.  Expired  messages  (percent)  as  a 
function  of  incoming  message  rate: 


100 


4.  Successfully  delivered  messages 
(percent)  as  a  function  of  incoming 
message  rate: 


these  findings,  the  data  from  both 
transponders  and  the  eight  separate 
tests  have  been  combined. 


Ps  =  100  x  =; 
“  N 


5.  Undetained  successful  deliveries 
(percent)  as  a  function  of  incoming 
message  rate: 


P 


u 


100  x 


M(0) 

N 


6.  Average  message  delivery  time  as  a 
function  of  incoming  message  rate: 

„  _  X(i  x  M(i)) 

T* - KmGJ) 


ANALYSIS  OF  DELAYED  MESSAGES.  Figure  24 
shows  that  there  were  no  messages  that 
generated  delay  notices.  The  output  of 
the  track  summary  data  reduction 
program  indicated  that  the  tracks  were 
in  roll-call  state  during  the  entire 
test,  which  means  that  no  sensor  ever 
missed  more  than  N  (site  adaptable  =  2) 
consecutive  reports  for  either  of  the 
test  transponders.  Since  delays  should 
not  occur  when  tracks  are  maintained  on 
roll-call,  the  data  link  function  is 
working  correctly  in  this  respect. 


7.  Distribution  of  delivery  times  for 
each  incoming  message  rate: 

- 100  *  wm 

GENERAL  PLOT  CHARACTERISTICS.  Eight 
tests  were  run  in  order  to  test  the 
data  link  function.  Unlike  that  used 
in  the  network  management  tests,  the 
flightpath  (pattern  B)  avoided  the 
zenith  cones  over  the  sensors  in 
order  to  prevent  interruptions  in  the 
accessibility  of  the  data  link. 

In  the  plots  that  follow,  the  value 
obtained  for  each  sensor  is  assigned  a 
unique  symbol:  a  plus  sign  for  the 
Technical  Center,  a  box  for  Elwood, 
and  a  cross  for  Clementon.  In  the 
S3  scenario  all  uplinks  addressed  to 
the  nonexistent  DABS  address  555553  were 
correctly  rejected  and  have  been 
omitted  from  the  data  in  order  to  avoid 
distortion  of  the  results. 

The  plots  were  examined  relative  to  the 
conditions  present  during  the  eight 
tests;  no  pattern  relating  to  multisite 
configuration  could  be  discerned. 
Separate  plots  made  for  7FFFFF  and 
FAADAB  showed  no  significant  difference 
in  the  data  link  behavior  of  the 
two  test  transponders.  In  line  with 


ANALYSIS  OF  COMPLETED  MESSAGES. 
Figure  25  shows  that  at  incident  message 
rates  of  two  through  five  (messages  per 
5-second  time  unit),  all  three  sensors 
complete  the  transactions  for  all 
incoming  messages,  which  is  to  say  that 
all  messages  are  delivered,  expired, 
or  rejected  and  none  is  lost.  At  an 
incoming  message  rate  of  six,  the 
probability  of  completion  at  the 
Elw<'od  sensor  drops  to  99  percent, 
while  remaining  at  100  percent  at  the 
other  two  sensors.  At  message  rates  of 
seven  and  eight,  a  decided  degradation 
can  be  observed.  At  a  message  rate  of 
seven,  the  Technical  Center's  percentage 
of  completion  is  99  percent,  Elwood's 
is  97  percent  and  Clementon' s  is 
92  percent.  At  a  message  rate  of  eight, 
the  value  at  the  Technical  Center 
dropped  to  92  percent,  at  Elwood  to 
91  percent,  and  at  Clementon  to 
84  percent. 

This  degradation  at  higher  message  rates 
result  from  factors  in  the  channel 
management  and  data  link  functions.  In 
the  version  of  channel  management  used 
for  these  tests,  the  maximum  number  of 
interrogations  that  could  be  scheduled 
was  six  per  scan.  The  value  six  comes 
about  because  the  effective  beam  width 
for  DABS  (90  azimuth  units,  as  deter¬ 
mined  by  the  value  of  a  site-adaptable 


parameter  known  as  THETAH)  theoretically 
allows  channel  management  to  schedule 
3.15  DABS  periods  per  aircraft  during 
the  beam  dwell.  With  only  one  or  two 
DABS  aircraft  in  the  beam,  channel 
management  will  generally  be  able  to 
accomplish  two  schedules  per  period  for 
a  total  of  six  interrogations.  Since 
channel  management  cannot  keep  up  with 
the  scan-after-scan  arrival  of  seven  or 
eight  tactical  uplink  messages,  the 
number  of  messages  in  the  queue  keeps 
increasing.  It  can  only  increase  to 
15  for  each  target  because  of  the  4-bit 
sizing  of  an  index,  known  as  the  entry 
indicator,  that  is  used  by  data  link 
processing  to  manage  the  waiting 
entries.  Additional  messages  arriving 
when  the  list  is  full  are  discarded. 
Since  no  provision  exists  to  notify  ATC 
of  this  "buffer  full"  condition,  the 
message  transaction  is  never  completed 
(no  rejection,  delivery,  or  expiration 
notice  is  ever  sent)  and  the  message 
is  "lost."  The  performance  monitor, 
however,  will  maintain  counts  of  this 
situation.  It  should  be  emphasized  that 
the  sensor  was  being  loaded  with  message 
rates  in  excess  of  ER  requirements  in 
order  to  determine  what  functions  would 
cause  the  resulting  degradation. 

The  completion  rates  shown  in  figure  25 
are  similar  for  the  Technical  Center 
and  Elwood  sensors,  but  they  are 
considerably  worse  for  Clementon.  The 
degraded  data  link  performance  resulted 
from  the  fact  that  during  these 
eight  tests  the  Clementon  sensor  showed 
a  significantly  greater  number  of  "no 
detect"  replies  to  interrogations, 
both  in  and  out  of  the  beam.  This 
phenomenon  is  not  understood  and  should 
be  investigated. 

ANALYSIS  OF  EXPIRED  MESSAGES.  Figure  26 
shows  that  at  lower  message  rates  there 
are  no  expirations,  a  consequence  of  the 
fact  that  at  these  rates  all  messages 
are  successfully  delivered.  At  message 
rates  of  six,  seven,  and  eight,  however, 
the  number  of  waiting  messages  increase 
in  the  manner  discussed  in  the  previous 
section.  The  number  of  expirations 


would  be  expected  to  rise  as  the 
messages  are  forced  to  wait  longer  in 
the  queue.  The  figure  shows  that  the 
percentage  of  expired  messages  never 
rises  above  one  percent,  and  even 
decreases  when  the  rate  is  increased 
from  seven  to  eight.  This  decrease  is 
deceptive  for  it  does  not  mean  that  the 
messages  are  being  delivered  at  a 
greater  rate.  It  does  reflect  the  fact 
that  fewer  messages  get  the  chance  to 
expire  because  they  are  discarded  as  a 
result  of  the  entry  indicator  sizing 
constraint  discussed  in  the  previous 
section. 

ANALYSIS  OF  SUCCESSFUL  DELIVERIES.  The 
data  shown  in  figure  27  are  similar  to 
that  presented  for  the  analysis  of 
completed  messages.  The  difference  is 
that  this  statistic  does  not  contain 
message  rejections  (of  which  there 
were  none  in  this  sample)  or  message 
expirations.  Since  there  were  only  a 
few  expirations  for  reasons  discussed 
earlier,  the  plots  of  completions  and 
of  successful  deliveries  are  almost 
identical . 

ANALYSIS  OF  UNDETAINED  MESSAGES. 
Figure  28  shows  the  plot  of  the 
statistic  which  measures  the  percentage 
of  messages  that  are  delivered 
within  one  time  unit  (5  seconds)  of 
transmission  from  the  STC. 

This  statistic  is  measured  in  time  units 
rather  than  scans  due  to  the  character¬ 
istics  of  the  Elwood  sensor.  The  data 
link  function  operates  on  a  half-scan 
basis  at  Elwood,  but  scan  markers 
are  recorded  only  once  a  scan  (every 
9.7  seconds).  The  data  at  the  other 
sensors  refer  to  a  4.7-second  scan, 
about  half  that  at  Elwood.  Therefore, 
time  units  were  used  to  measure  the  data 
at  all  sites.  For  rates  of  two  through 
five,  the  percent  undetained  is  in  the 
90's  for  the  Technical  Center  and 
Clementon  and  is  in  the  80' s  for  Elwood. 
The  explanation  of  the  difference 
lies  in  the  respective  antenna  scan 
rates.  The  Elwood  sensor  is  an  en  route 
sensor,  having  a  back-to-back  antenna 
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FIGURE  26.  ANALYSIS  OF  EXPIRED  MESSAGES 
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FIGURE  28.  ANALYSIS  OF  UNDETAINED  MESSAGES 


and  a  scan  rate  of  9.7  seconds;  whereas, 
the  others  are  terminal  sensors  having 
scan  rates  of  4.7  seconds.  In  one  time 
unit  the  terminal  sensor  antennas  travel 

-  7 *  1.06  scans  . 

4.7 

The  en  route  antenna  travels 
=  1-03  scans 

between  antenna  faces  in  one  time  unit. 
Data  link  message  processing  is  handled 
on  a  scan  basis,  and  since  the  terminal 
sensors  have  more  scans  between  message 
blocks,  they  appear  to  deliver  their 
messages  in  fewer  time  units.  The 
result  is  a  higher  percentage  of 
undetained  messages  for  the  Technical 
Center  and  Clementon  than  for  Elwood. 

At  a  message  rate  of  six,  the  percentage 
of  undetained  messages  at  Elwood  and 
Clementon  both  drop  off.  However,  at  a 
rate  of  seven  for  Clementon  and  a  rate 
of  eight  for  the  Technical  Center  and 


Elwood,  there  is  a  large  decrease. 
The  drop  occurs  sooner  at  Clementon  than 
at  the  other  two  sensors  because  of  the 
greater  frequency  of  "no-detects,"  as 
mentioned  previously.  At  a  message  rate 
of  eight,  the  statistic  for  undetained 
messages  is  about  10  percent  for  each  of 
the  three  sensors.  This  value  reflects 
the  fact  that  at  this  rate  none  of  the 
sensors  can  keep  up  with  the  incoming 
messages.  Initially,  when  the  first  few 
blocks  of  a  message  arrive,  some  of  the 
messages  are  delivered  within  one  time 
unit.  As  more  and  more  blocks  arrive, 
however,  the  sensors  all  reach  a 
state  in  which  almost  all  (if  not  all) 
messages  are  detained. 

ANALYSIS  OF  AVERAGE  DELIVERY  TIME. 
Figure  29  shows  the  statistic  that 
measures,  on  an  average,  how  many  time 
units  are  required  for  message  delivery. 
For  the  same  reasons,  discussed  earlier 
in  conjunction  with  the  "Analysis  of 
Undetained  Messages"  (figure  28),  the 
average  delivery  times  for  the  Technical 
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FIGURE  29.  ANALYSIS  OF  AVERAGE  DELIVERY  TIME 


Center  and  Clementon  sensors  are  similar 
at  incoming  message  rates  of  two  through 
five,  and  Elwood's  average  is  higher 
across  the  same  interval.  The  same 
reasoning  used  to  explain  the  differ¬ 
ences  at  rates  of  six,  seven,  and  eight 
also  applies.  Through  an  incoming 
message  rate  of  seven,  the  Technical 
Center  and  Elwood  sensors  maintain  a 
value  of  the  average  delivery  time,  Ta, 
which  is  less  than  half  a  time  unit.  At 
a  rate  of  seven,  Clementon  has  Ta  ■  1.1 
time  units.  At  a  message  rate  of  eight, 
Ta  is  less  than  1.5  time  units  for  all 
three  sensors.  Since  Ta  is  measured  in 
time  units  and  the  average  value  for  an 
interval  is  its  midpoint,  seconds  equals 
time  units  multiplied  by  5  plus  2.5. 
For  example:  Ta  *  0.5  time  units 
corresponds  to  5  seconds. 

ANALYSIS  OF  DELIVERY  TIME  DISTRIBUTION. 
Figures  30  through  36  show  the  delivery 
time  distribution  for  message  rates 
of  two  through  eight,  respectively. 
This  statistic  measures  the  ratio  of 
messages  delivered  within  i  time  units 


(where  i  *  0,1,2. ..,7)  to  the  total 
number  of  messages  delivered. 

At  message  rates  of  two  through  five, 
the  terminal  sensors  deliver  within  one 
time  unit  at  least  90  percent  of  the 
total  number  of  messages  delivered; 
the  Elwood  sensor  delivers  at  least 
80  percent.  The  difference  between  the 
en  route  and  terminal  sensors,  in  this 
respect,  has  already  been  discussed 
previously  in  the  "Analysis  of  Undelayed 
Messages"  section.  During  the  next  time 
unit  the  sensors  deliver  all  their 
remaining  messages. 

At  a  message  rate  of  six,  90  percent  of 
the  messages  delivered  by  the  Technical 
Center  are  delivered  within  the  first 
time  unit  and  10  percent  are  delivered 
during  the  next.  Elwood  delivers 
70  percent  within  the  first  time  unit, 
25  percent  during  the  second,  and 
5  percent  during  the  third. Clementon' s 
figures  are  75  percent  and  25  percent 
for  the  first  and  second  time  units, 
respect ively . 
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FIGURE  30.  MESSAGE  DELIVERY  TIME  FOR  MESSAGE  RATE  OF  TWO  PER  SCAN 


FIGURE  31.  MESSAGE  DELIVERY  TIME  FOR  MESSAGE  RATE  OF  THREE  PER  SCAN 
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FIGURE  32. 


FIGURE  33. 


MESSAGE  DELIVERY  TIME  FOR  MESSAGE  RATE  OF  FOUR  PER  SCAN 


MESSAGE  DELIVERY  TIME  FOR  MESSAGE  RATE  OF  FIVE  PER  SCAN 
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FIGURE  36.  MESSAGE  DELIVERY  TIME  FOR  MESSAGE  RATE  OF  EIGHT  PER  SCAN 


At  a  message  rate  of  seven,  60  percent 
of  all  messages  delivered  by  the 
Technical  Center  are  delivered  within 
the  first  time  unit,  35  percent  in  the 
second,  and  5  percent  in  the  third. 
Elwood  has  similar  figures.  Clementon, 
on  the  other  hand,  has  quite  a  different 
distribution.  Because  of  the  greater 
number  of  "no  detects"  at  Clementon, 
that  sensor  reaches  a  state  sooner  in 
which  almost  all  messages  are  being 
detained.  Thus,  only  22  percent  of  the 
messages  delivered  are  delivered 
within  the  first  time  unit.  This  value 
increases  to  48  percent  during  the 
second  time  unit,  28  percent  in  the 
third,  and  2  percent  in  the  fourth. 

At  a  message  rate  of  eight,  all  three 
sensors  deliver  10  to  15  percent  of 
their  delivered  messages  within  the 
first  time  unit.  The  Technical  Center 
and  Elwood  deliver  65  percent  during 
the  second,  and  Clementon  47  percent. 
During  the  third,  the  Technical  Center 
and  Elwood  fall  to  15  percent  and 


22  percent,  respectively,  and  Clementon 
drops  to  35  percent.  During  the  fourth 
time  unit,  all  three  sensors  deliver 
about  one  to  three  percent  of  the  total 
messages  that  they  deliver. 

The  significance  of  this  distribution  is 
that  at  message  rates  of  two  through 
five,  all  messages  were  delivered  within 
two  time  units  (12.5  seconds)  and 
most  were  delivered  within  one  time  unit 
(7.5  seconds).  At  higher  incoming 
message  rates  this  distribution  becomes 
skewed  toward  longer  delivery  times. 

INTERSENSOR  COMMUNICATIONS. 

ADJACENT  SENSOR  STATUS  CHECKS.  On  a 
periodic  basis,  each  sensor  that  has 
a  connection  to  a  neighboring  sensor 
will  attempt  to  ascertain  the  condition 
of  any  other  netted  sensor  whose 
scan-by-scan  status  reports  are  not 
being  received.  Examination  of  dumps 
obtained  from  a  data  reduction  program 
known  as  "quick  look  STC  extraction" 


(QSTCE)  showed  that  status  requests 
about  a  third  sensor's  condition  were 
being  sent  on  schedule,  and  responses 
about  that  third  sensor's  condition  were 
being  returned  with  the  correct  content. 

ADJACENT  SENSOR  CPME  CHECKS.  Each 
sensor  is  required  to  obtain  track 
data  on  its  connected  neighbors'  CPME's 
on  a  periodic  basis  and  report  detection 
of  any  positional  discrepancies  by  means 
of  a  code  in  the  sensor-to-ATC  status 
message  once  per  scan.  Correct  perform¬ 
ance  has  been  verified  in  conjunction 
with  day-to-day  testing. 

STC  MESSAGE  SUMMARY.  Table  3  shows  a 
sample  message  summary  obtained  from 
the  QSTCE  analysis  program  after  a 
two-sensor  (Technical  Center/Clementon) 
connected  run.  The  CIDIN  messages  are 
listed  first  and  are  broken  into  cate¬ 
gories  of  message  type,  source,  and 
destination.  Certain  message  types 
(such  as  type  01  northmark  messages, 
type  71  status  messages  to  other 
sensors,  and  type  64  status  messages  to 
ATC  facilities)  are  sent  once  per  scan, 
so  the  counts  of  these  messages  should 
be  within  one  unit  of  being  equal  to 
each  other  and  being  equal  to  the 
number  of  scans  represented  by  the 
test.  Any  discrepancy  would  indicate  a 
communications  interruption  or  other 
malfunction. 

The  number  of  type  72  status  inquiries 
about  a  third  sensor  (Elwood  is  missing 
in  this  example)  sent  to  a  neighboring 
sensor  should  be  equal  to  the  number 
of  type  73  status  responses  received 
from  that  neighbor.  The  same  logic 
applies  to  type  9E  requests  about  a 
neighbor's  CPME  and  type  9F  responses 
about  that  CPME.  Table  3  shows  the 
outgoing  and  incoming  values  to  be  equal 
in  all  appropriate  cases. 

In  this  example,  the  number  (2,520)  of 
incoming  type  21  tactical  uplink 
messages  to  be  data-linked  to  the 
aircraft  is  in  excess  of  the  combined 
count  of  possible  responses  22  type 


31  message  rejection/delay  notices  and 
2,463  type  32  message  delivered /expired 
notices,  giving  a  total  of  2,485.  These 
missing  messages  result  from  an  index 
sizing  problem  already  discussed  in  the 
''Analysis  of  Completed  Messages"  of  the 
"Data  Link  Message  Processing"  section. 

Type  45  ATCRBS  ID  messages  do  not  appear 
at  all  as  these  were  deliberately 
suppressed  during  testing.  There  is 
also  a  large  number  (497)  of  type  9D 
DABS  coordination  messages  sent  by  each 
of  the  sensors  as  a  result  of  operating 
in  the  special  mode  (with  the  Elwood 
sensor  failed). 

An  unexpectedly  high  count  (28)  of  type 
93  track  data  requests  were  sent  from 
Clementon  to  the  Technical  Center,  a 
large  number  (385)  of  external  DABS 
track  data  messages  were  sent  to 
Clementon  in  response,  and  a  rather  high 
incidence  (32)  of  type  44  data  link 
capability  messages  went  from  Clementon 
to  ATC.  The  number  of  type  44  messages 
is  an  indirect  measure  of  the  number 
of  times  a  DABS  track  transitioned 
into  roll-call  state  from  some  other 
track  state.  All  of  these  higher  than 
expected  counts  arise  from  the  observed 
phenomenon  that  Clementon  is  unable  to 
track  the  mizpah  parrot  solidly.  Most 
of  the  time  the  parrot  is  being  main¬ 
tained  on  external  data  of  Clementon, 
but  random  local  hits  will  cause 
Clementon  to  transition  the  track  to 
roll-call  for  a  scan  or  two  before  the 
parrot  fades  and  external  data  are  once 
again  requested. 

No  hard  and  fast  conclusions  may  be 
drawn  from  the  other  numbers,  which  are 
inspected  for  reasonableness  and  which 
give  some  idea  of  the  average  CIDIN 
message  loading  encountered  during  the 
test . 

The  surveillance  portion  of  the  table 
shows  that  1,043  DABS  reports  (test 
aircraft,  parrot,  and  CPME)  were 
disseminated  to  the  ATC  facility  from 
the  Technical  Center  and  606  targets 


TABLE  3.  STC  MESSAGE  SUMMARY 


Mes  sage 

SEN  3 

SEN1 

SEN1 

SEN  3 

STC 

SEN1 

Type 

Message 

To 

To 

To 

To 

To 

To 

Code 

Type 

SEN1 

SSF 

SEN  3 

SSF 

SEN1 

STC 

01 

Northmark 

339 

0 

339 

0 

0 

0 

21 

Tactical  Uplink 

0 

0 

0 

0 

2,520 

0 

31 

Message  Rejection/Delay 

0 

0 

0 

0 

0 

22 

32 

Message  Delivery /Expiration 

0 

0 

0 

0 

0 

2,463 

44 

Data  Link  Capability 

0 

2 

0 

32 

0 

0 

64 

Sensor  to  ATC  Status 

0 

339 

0 

339 

0 

0 

71 

Sensor  to  Sensor  Status 

339 

0 

339 

0 

0 

0 

72 

Status  Request  (Third) 

16 

0 

16 

0 

0 

0 

73 

Status  Response  (Third) 

16 

0 

16 

0 

0 

0 

83 

Controller  Alert 

0 

7 

0 

10 

0 

0 

91 

DABS  Track  Data  Start 

33 

0 

29 

0 

0 

0 

92 

DABS  Track  Data  Stop 

33 

0 

30 

0 

0 

0 

93 

DABS  Track  Data  Request 

28 

0 

1 

0 

0 

0 

94 

DABS  Track  Data  Message 

13 

0 

385 

0 

0 

0 

95 

DABS  Cancel  Request 

30 

0 

33 

0 

0 

0 

9D 

DABS  Coordination 

497 

0 

497 

0 

0 

0 

9E 

External  CPME  Request 

22 

0 

22 

0 

0 

0 

9F 

External  CPME  Response 

22 

0 

22 

0 

0 

0 

D1 

ATCRBS  Track  Data  Start 

187 

0 

31 

0 

0 

0 

D2 

ATCRBS  Track  Data  Stop 

98 

0 

63 

0 

0 

0 

D3 

ATCRBS  Track  Data  Request 

133 

0 

371 

0 

0 

0 

D4 

ATCRBS  Track  Data  Message  2 

,945 

0 

225 

0 

0 

0 

D5 

ATCRBS  Cancel  Request 

57 

0 

210 

0 

0 

0 

FI 

Surveillance  Reports 

0 

1,043 

0 

606 

0 

0 

Surveillance  Messages  -  SEN1  to 

SSF 

DABS  ATCRBS 

Radar 

Beacon 

i  Only  1 ,043  0 

Radar 

Substituted  0  0 

Radar 

Reinforced  0  0 

Radar  Only 

0 

Alerts 

i  0 

Code  in  Transition  0 

False  Target  Reports  0 

Radar 

Status  Reports 

0 

Search 

i  RATQC  Reports 

0 

Radar 

Strobe  Reports 

0 

Radar  Map  Reports 

0 

Surveillance  Messages  -  SEN3  to 

SSF 

DABS  ATCRBS 

Radar 

Beacon  Only  606  0 

Radar  Substituted  0  0 

The  remainder  of  the  table  is  the  same  as  above  and  is  omitted. 
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(test  aircraft,  CPME ,  and  occasional 
reports  from  the  parrot)  were  sent  from 
Clementon.  Radar  targets  were  not  used 
during  this  round  of  testing  and  ATCRBS 
targets,  although  disseminated  to  the 
ATC  facilities,  were  not  selected 
for  STC  recording. 


SUMMARY  OF  RESULTS 


NETWORK  MANAGEMENT. 

1.  DABS  sensors  which  were  connected  to 
each  other  exchanged  remote  track  data, 
allowing  tracking  through  the  cones 
of  silence. 

2.  Connected  sensors  satisfactorily 
accomplished  primary/ secondary  coordi¬ 
nation  procedures,  as  dictated  by 
the  network  coverage  maps  and  the 
controlled/uncontrolled  status  of  the 
DABS  track. 

3.  Where  at  least  one  unconnected 
sensor's  surveillance  coverage  over¬ 
lapped  that  of  other  sensors,  the 
intermittent  lockout  scheme  was  properly 
invoked  and  successfully  executed  by  all 
primary  sensors. 

4.  In  the  case  of  proximate 
transponders,  the  unlock  sequence  was 
shown  to  be  adequately  extended  in 
order  to  stagger  the  beginning  of  the 
lock/unlock  periods. 

5.  Control  state  messages  sent  to 
the  sensor  from  the  STC  serving  as 
a  simulated  ATC  facility  correctly 
modified  the  handling  of  tracks  by  the 
network  management  function. 

6.  The  presence  of  a  duplicate  DABS 
address  within  the  surveillance  area  of 
a  sensor  correctly  causes  removal  of  the 
track  from  the  surveillance  file  to 
the  duplicate  address  alert  table  and 
the  subsequent  issuance  of  track  alert 
messages. 


7.  The  DABS  engineering  requirement 
(FAA-ER-260-26)  specifies  a  one-bit  word 
for  the  special  mode  flag  associated 
with  each  target.  The  length  of  this 
field  is  insufficient  to  specify  the 
failure  of  more  than  one  adjacent 
sensor.  The  result  is  additional 
processing  required  on  each  scan 
for  each  target  during  conditions  of 
adjacent  sensor  failure. 

8.  The  target  special  mode  flag  was 
intended  to  signify  the  existence  of 
an  adjacent  sensor  failure  condition 
at  the  time  of  track  update.  In  the 
current  implementation  it  is  also  used 
to  indicate  the  failure  of  intersensor 
communications,  resulting  in  an  addi¬ 
tional  processing  load  on  each  scan 
for  each  target  during  conditions  of 
communications  failure  or  tests 
involving  unconnected  sensors. 

9.  Guidelines  for  the  building  of 
network  management  coverage  maps  specify 
that  the  geographical  area  for  which 
the  sensor  is  primary  is  that  closest 
to  the  sensor  site.  Such  a  region 
necessarily  includes  the  cone  of  silence 
over  the  sensor  in  which  the  local 
sensor  is  unable  to  communicate  with  the 
aircraft.  Delays  of  as  many  as  20  scans 
have  been  observed  between  the  time  that 
the  aircraft  transitioned  to  remote  data 
and  the  time  that  handoff  of  primary 
status  to  an  adjacent  sensor  occurred. 
A  downlink  message  originated  during 
this  time  would  have  been  delayed  until 
the  primary  handoff  occurred. 

10.  In  some  of  the  tests  involving 
Clementon  as  an  unconnected  sensor,  the 
live  DABS  track  was  dropped  for  several 
scans  because  of  duplicate  address 
processing  arising  from  receipt  of 
All-Call  reflections  having  the  same 
DABS  address  as  that  of  the  roll-call 
track.  The  sensor's  response  to  the 
condition  was  correct;  however,  such 
situations  could  have  been  avoided  if 
the  presence  of  the  reflector  had 
been  anticipated  and  included  in  the 
Clementon  reflector  file. 
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11.  When  multiple  sensors  are  supplying 
remote  track  data,  one  data  stream  is 
flagged  to  be  retained  for  use  in  track 
update  and  the  other  is  to  be  discarded. 
One  of  the  tests  showed  that  if  the 
incoming  data  stream  is  halted  as  a 
result  of  communications  failure,  the 
flag  is  not  cleared.  This  problem  has 
been  fixed. 

12.  A  sensor  receiving  remote  track 
data  from  more  than  one  adjacent  sensor 
is  unable  to  determine,  in  some  cases, 
which  adjacent  sensor  supplied  the  data 
used  to  update  the  track.  The  problem 
did  not  interfere  with  the  current  test 
effort,  but  it  has  been  fixed  in  order 
to  facilitate  future  testing. 

SURVEILLANCE  PROCESSING. 

1.  The  surveillance  BSR  for  the 
DABS-equipped  aircraft  was  never  less 
than  99.5  percent  at  each  of  the  three 
sensors,  exclusive  of  the  sensor's  own 
zenith  cone. 

2.  The  multisite  surveillance  BSR 
ratio  overall  for  the  DABS  test  aircraft 
was  99.7  percent. 

3.  The  DABS  ID  reliability  for  the 
test  aircraft  was  always  100  percent. 

4.  The  DABS  altitude  reliability  for 
roll-call  reports  from  the  test  aircraft 
was  always  100  percent. 

5.  The  number  of  DABS  interrogations 
per  scan  for  the  test  aircraft  was  1.04, 
which  is  well  within  acceptable  limits. 

DATA  LINK  PROCESSING. 

1.  At  message  rates  of  two  through 
five  (incident  messages  per  5-second 
time  unit),  all  messages  were 
successfully  delivered. 

2.  For  two  through  five  messages 
per  aircraft  for  each  scan,  more  than 
90  percent  of  the  messages  for  the 
terminal  sensors  were  successfully 


delivered  without  delay.  The  corres¬ 
ponding  values  for  the  en  route  sensor 
exceeded  80  percent.  The  difference 
between  the  terminal  and  en  route 
antenna  scan  rates  is  responsible  for 
the  difference  in  percentage. 

3.  At  message  rates  of  seven  and  eight, 
the  data  link  performance  deteriorates. 
Messages  are  lost  because  the  data  link 
buffer  structure  cannot  accommodate 
more  than  15  messages  at  a  time. 
Consequently,  buffers  are  being  filled 
faster  than  they  can  be  emptied,  and 
some  of  the  incoming  messages  are 
discarded.  However,  even  in  the  worst 
case,  the  percentage  of  messages 
successfully  delivered  was  84  percent. 

4.  The  sensor  handled  message  rejection 
and  message  delay  conditions  perfectly. 

5.  Until  the  message  rate  exceeds 
the  number  of  times  the  sensor  can 
interrogate  while  the  target  is  in  the 
beam,  the  average  delivery  time  is  less 
than  0.5  time  units,  or  5  seconds. 

6.  The  size  of  the  data  link  entry 
indicator  is  currently  implemented  as 
a  4-bit  field,  containing  a  maximum 
value  of  15  and,  therefore,  allowing 
only  15  messages  per  individual  aircraft 
to  be  in  the  queue  awaiting  uplink 
delivery.  This  caused  queue  overflow 
with  resultant  message  loss. 

7.  Because  of  the  limitations  on  the 
size  of  the  individual  data  link  message 
queues,  most  messages  that  would  have 
expired  were  discarded  before  they  had  a 
chance  to  expire. 

8.  No  provision  has  been  made  for 
positive  notification  to  the  sender  of  a 
data  link  message  that  the  message  has 
been  discarded  for  lack  of  an  available 
data  link  entry  indicator  or  lack  of 
space  in  the  queue. 

9.  The  Clementon  sensor  showed  a 
significantly  greater  number  of  "no 
detect"  replies  to  interrogations  both 
in  and  out  of  the  beacon. 


INTERSENSOR  COMMUNICATIONS. 


1.  Sensors  in  a  DABS  network  make 
periodic  requests  for  status  of 
adjacent  connected  sensors  from  which 
no  scan-by-scan  messages  are  being 
received.  The  replies  to  these  requests 
are  successfully  used  to  infer  condi- 
t ions  of  failure,  either  of  a  sensor  or 
its  communication  lines. 

2.  Sensors  in  a  DABS  network  also 
make  periodic  reauests  for  track  data 
information  concerning  the  CPME  at 
adjacent  sensors.  The  track  data 
messages  received  in  reply  are  checked 
for  range,  azimuth,  and  altitude. 
Ou t - o f- t o  1  e r a n c e  conditions  are 
correctly  reported  in  the  sensor-to-ATC 
status  message. 

3.  Communicat ions  intergrity  has  been 
verified  by  observing  that  equivalent 
numbers  of  messages  pass  across  the 
s e ns o r - t o- s e ns o r  lines  in  both 
directions,  and  the  counts  of  sensor-to- 
National  Air  Space  messages  are  as 
expected. 

CONCLUSIONS 


NETWORK  MANAGEMENT. 

The  Discrete  Address  Beacon  System 
(DABS)  network  management  concept  has 
proven  itself  to  be  workable  and 
supports  multisensor  operation  in  all 
configurations  from  fully  netted  to 
fully  nonnetted. 

Testing  of  the  network  management 
function  revealed  some  minor  coding 
errors  which  are  in  the  process  of 
being  corrected.  Some  performance 
deficiencies  were  noted  and  recommen¬ 
dations  were  developed  that  may  improve 
the  performance  of  future  systems. 

SURVEILLANCE  PROCESSING. 

The  multisite  surveillance  processing 
tested  indicated  excellent  performance 


from  the  sensors  with  respect  to  the 
DABS  equipped  aircraft. 

DATA  LINK  PROCESSING. 

The  data  link  function,  tested  in  a 
multisite  configuration  with  one 
DABS  test  aircraft  in  the  beam,  met  or 
exceeded  the  requirements  specified 
in  the  Federal  Aviation  Administration 
(FAA)  DABS  engineering  requirement 
(FAA-ER-240-26) .  The  limitations  noted 
resulted  from  the  limits  in  the. 
capability  of  channel  management 
to  schedule  interrogations.  In  the  real 
world  environment,  so  long  as  messages 
are  not  sent  at  rates  that  exceed  the 
capabilities  of  channel  management, 
the  number  of  incomplete  message 
transactions  should  be  insignificant. 

INTERSENSOR  COMMUNICATIONS . 

Tests  involving  adjacent  sensors  in  the 
DABS  network  are  performed  correctly  and 
evidence  was  obtained  that  sensor-to- 
sensor  communications  and  sensor-to-air 
traffic  control  (ATC)  communications 
perform  as  expected,  considering  the 
available  real  world  target  load 
(approximately  100  Air  Traffic  Control 
Radar  Beacon  System  (ATCRBS)  targets  per 
sensor  and  one  DABS  test  aircraft).  No 
loss  of  data  was  experienced. 


RECOMMENDATIONS 


NETWORK  MANAGEMENT. 

The  following  recommendations  are 
made : 

1.  The  target  special  mode  flag  should 
be  increased  to  a  nominal  16  bits  to 
match  the  system  special  mode  flag  and 
contain  information  concerning  the  state 
of  each  adjacent  sensor  at  the  time  of 
target  update. 

2.  In  addition  to  the  target  special 
mode  flag,  records  of  sensor-to-sensor 
communications  failure  should  be  kept 
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distinct  from  records  of  adjacent  sensor 
failure  and  saved. 

3.  Whenever  an  aircraft  which  is  in  the 
zenith  cone,  transitions  from  roll-call 
tracking  to  external  data  and  the  local 
sensor  is  primary,  the  local  sensor 
should  send  a  message  to  all  adjacent 
assigned  sensors.  The  recipients  of 
this  message  should  set  a  flag  in  the 
surveillance  file  that  will  trigger  a 
surveillance  boundary  crossing  on 
the  next  scan.  This  flag  should  be 
cleared  as  a  part  of  the  routine 
boundary  crossing  procedure.  The  result 
of  these  actions  should  decrease 
the  time  required  for  an  adjacent 
sensor  to  become  primary  and  initiate 
readout  of  pilot-originated  downlink 
messages . 

4.  The  reflectors  in  the  vicinity  of 
Clementon  should  be  identified  and 
included  in  the  Clementon  reflector 
file.  The  Clementon  sensor  should  then 


be  retested  with  respect  to  All-Call 
reflections. 

DATA  LINK  PROCESSING. 

1.  Additional  testing  should  be 
conducted  following  the  installation 
of  the  upgraded  channel  management 
function.  If  message  loading  continues 
to  be  a  problem,  a  study  should  be  made 
to  determine  the  optimum  size  to  which 
the  data  link  entry  indicator  should  be 
increased . 

2.  Message  expiration  statistics  should 
be  reexamined  after  the  recommendation 
of  No.  1  above  are  implemented. 

3.  If  a  message  is  discarded  by  the 
data  link  function  the  originator  of  the 
message  should  be  notified. 

4.  Further  tests  should  be  conducted 
at  the  Clementon  sensor  in  an  attempt 
to  reproduce  and  explain  the  large 
number  of  no  detect  replies. 
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APPENDIX  A 

LOAD  TAPES  AND  SITE  ADAPTATION  CASSETTES 


TECHNICAL  CENTER  SENSOR. 

Sensor  load  tape:  316N11  Release  7.2 

Multisite  test  tape  with  "stand 
alone"  network  management,  upgraded 
Data  Interchange  Network  (CIDIN), 
and  site  1  coverage  map. 

Data  extraction  cassette:  DX-8  (collects 
Discrete  Address  Beacon  System  (DABS) 
replies) 

Site  adaptation  cassettes:  N-120, 
A-110,  and  A-103 


Data  extraction  cassette:  DX-8  (collects 
DABS  replies) 

Site  adaptation  cassettes:  E-123, 
A-110,  A-103 

E-123  (Special  adaptation  for 
Elwood  sensor  (back-to-back 
antenna,  site  2  ID,  CPME 
data,  and  adjacent  sensor 
list),  and 

A-110  Standard  multisite  activation 
and  communication  parameters 
for  loopback  mode,  or 

A-103  Standard  single  site 
parameters  for  loopback  mode. 

CLEMENTON  SENSOR. 


N-120  Special  adaptation  for 
Technical  Center  sensor 
(site  1  identifies  (ID), 
calibration  and  performance 
monitoring  equipment  (CPME) 
data,  and  adjacent  sensor 
list),  and 

A-110  Standard  multisite  activation 
and  communication  parameters 
for  loopback  mode,  or 

A-103  Standard  single  site 
parameters  for  loopback  mode. 

ELWOOD  SENSOR. 

Sensor  load  tape:  316E16  Release  7.2 

Multisite  test  tape  with  "stand 
alone"  network  management ,  upgraded 
CIDIN,  and  site  2  coverage  map. 


Sensor  load  tape:  316C11  Release  7.2 

Multisite  test  tape  with  "stand 
alone"  network  management,  upgraded 
CIDIN,  and  site  3  coverage  map. 

Data  extraction  cassette:  DX-8  (collects 

DABS  replies) 

Site  adaptation  cassettes:  C-118,  A-110 

C-118  Special  adaptation  for 
Clement on  sensor  (site  3  ID, 
CPME  data,  and  adjacent 
sensor  list),  and 

A-110  Standard  multisite  activation 
and  communication  parameters 
for  loopback  mode. 
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APPENDIX  B 

NETWORK  MANAGEMENT  DATA  REDUCTION 


Automated  data  reduction  were  used  as 
much  as  practicable  in  obtaining  the 
results  described  in  this  report. 
Computer  programs  capable  of  processing 
the  data  extraction  and  STC  tapes 
described  previously  are  available 
on  the  Honeywell  66/60,  the  Digital 
Equipment  Corporation  (DEC)  PDP-11,  and 
the  Texas  Instruments  (TI)  990  computer 
systems.  The  remaining  analysis  was 
accomplished  manually  by  inspection  of 
data  dumped  from  the  tapes. 

HONEYWELL  66/60  PROGRAM. 

A  program  for  processing  STC  tapes  on 
the  Honeywell  66/60  computer  was  one 
of  the  principal  data  reduction  tools 
used  in  developing  data  for  this  report. 
It  has  the  following  user-specified 
options: 

1.  Hexadecimal  dump.  The  user  may 
request  that  each  record  dumped  from  the 
tape  be  followed  by  its  hexadecimal 
equivalent . 

2.  Formatted  dump.  Each  record  is 
divided  into  individual  data  fields  and 
labelled  accordingly.  Conversion  to 
more  customary  systems  of  units  are  made 
(i.e.,  range  is  expressed  in  nautical 
miles  instead  of  the  Discrete  Address 
Beacon  System  (DABS)  "range  units;" 
azimuth  is  expressed  in  degrees). 

3.  Fi  1 tered  copy .  Use r-s pe c i f i ed 
record  types  can  be  copied  to  tape  or 
disc  in  the  same  format  as  on  the  input 
tape.  The  unwanted  record  types  are 
discarded. 

4.  Multisite  time  profile.  The  user 
may  request  a  formatted  dump,  which  is 
listed  in  columnar  fashion,  one  column 
per  sensor,  with  the  vertical  dimension 
representing  a  time  line.  DABS  and  Air 


Traffic  Control  Radar  Beacon  System 
(ATCRBS)  surveillance  file  entries  are 
listed  in  an  abbreviated  form. 

5.  Network  management  status  and 
lockout  analysis.  This  program  produces 
a  formatted  scan-by-scan  listing  of  the 
essential  network  management  parameters 
such  as  lockout  state,  lock/unlock 
count,  sensor  priority  status,  assigned 
sensor 8,  INLIST,  and  OUTLIST  (see  item  2 
of  "Multisite  Netter  Results"  in  the 
Network  Management  Data  Analysis 
section).  The  program  flags  changes  in 
state  for  convenient  reference. 

6.  Plot  of  selected  tracks.  The 
des  ired  track(s)  are  specified  by 
aircraft  identification  (ID). 

7.  Track  summary.  The  following  items 
are  listed  for  each  DABS  ID  and  site: 
number  of  scans,  number  of  points,  all 
surveillance  file  numbers,  number  of 
updates  to  each  track  state  (coast, 
All-Call,  roll-call,  and  external), 
number  of  scans  in  zenith  cone,  and 
blip/scan  ratio  (BSR)  (overall  and 
corrected  for  the  zenith  cone.) 

8.  Flagging  for  formatted  dump. 
Each  change  in  track  status  deemed 
"interesting"  is  listed  along  with  the 
scan  number  on  which  it  occurred.  When 
the  formatted  dump  is  used,  the  flagging 
is  listed  immediately  after  the  surveil¬ 
lance  file  entry  which  caused  it. 

PDP-11  PROGRAMS. 

For  the  sake  of  convenience  and  rapid 
data  analysis,  plot  programs  showing  the 
track(s)  of  selected  aircraft  were  made 
available  on  the  DEC  PDP-11  computer, 
which  is  physically  located  in  the  same 
building  as  the  Technical  Center  sensor 
and  the  system  test  console  (STC) . 
Immediate  turnaround  of  plot  data 
between  live  tests  were  available 
when  necessary.  The  following  plot 
capabilities  were  used: 
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1.  Using  Che  STC  Cape,  Che  user  may 
obCain  ploCs  of  aircrafC  position  as 
given  by  surveillance  file  daCa  recorded 
in  Che  special  Cype  90  Crack  snapshoc 
messages.  PloCs  show  boch  locally  and 
exCernally  supplied  daCa  and  may 
be  obCained  using  an  opcion  in  which 
special  symbols  are  used  Co  differen- 
ciate  among  possible  Crack  sCaCes  such 
as:  coasC,  exCernal,  local  (boCh  primary 
and  secondary),  and  radar  reinforced. 

2.  From  Che  daCa  exCracCion  Cape,  ploCs 
of  All-Call  replies  may  be  obCained 
which  show  Che  sequences  during  which 
Che  DABS  Cransponder  was  unlocked  to 
All-Call. 

3.  The  data  extraction  Cape  can  be 
used  to  produce  plots  of  surveillance 


reports  disseminated  Co  any  (or  Co  all) 
facilities.  The  reports  may  be  filtered 
by  report  Cype  such  as:  radar  only, 
radar  reinforced,  and  beacon. 

TI  990  PROGRAM. 

The  TI  990  program  development  system 
was  used  for  running  Che  quick  look 
STC  extraction  program  (QSTCE).  This 
program  allowed  filtering  of  messages 
by  message  type,  aircrafC  ID  (if 
appropriate),  and  surveillance  position 
within  a  specified  range  of  a  given 
target.  Rapid  turnaround  of  Data 
Interchange  Network  (CIDIN)  message 
dumps  could  be  obtained  as  well  as  a 
summary  of  message  types  sent  between 
various  sourcen  and  destinations. 


APPENDIX  C 

SURVEILLANCE  PROCESSING  DATA  REDUCTION 


Among  the  data  reduction  and  analysis 
programs  developed  by  the  Federal 
Aviation  Administration  (FAA)  Technical 
Center  personnel  is  a  real  world 
analysis  program  which  was  used  to 
obtain  the  surveillance  performance 
statistics  contained  in  this  report. 
The  real  world  analysis  program  runs  on 
the  Honeywell  66/60  computer  and  uses  as 
input  the  Discrete  Address  Beacon  System 
(DABS)  target  reports  contained  on  a 
sensor  data  extraction  tape.  If  a 
target  report  appears  on  two  consecutive 
scans,  the  analysis  program  initiates  a 


track  on  the  target  and  maintains  a 
count  of  the  number  of  scans  during 
which  a  target  report  appeared  and  a 
count  of  the  number  of  scans  on  which 
that  target  report  correlated  the  track. 
The  blip/scan  ratio  (BSR)  for  an 
individual  aircraft  is  computed  by 
dividing  the  latter  count  by  the  former 
one  and  multiplying  by  100.  The 
summation  of  the  BSR  values  for  all 
aircraft  over  a  specified  time  interval 
is  used  to  compute  an  average  BSR 
value  for  the  sensor.  The  filtering 
parameters  used  to  obtain  these  results 
consisted  of  range  values  between  A  to 
69  nautical  miles,  all  azimuths  except 
for  those  of  known  reflectors,  and  all 
elevation  angles. 
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APPENDIX  D 

DATA  LINK  DATA  REDUCTION 

Automated  data  reduction  programs  were 
created  for  use  on  the  Honeywell  66/60 
computer.  These  programs  make  use  of 
the  system  test  console  (STC)  recording 
tape  or  a  sensor  data  extraction  tape, 
as  discussed  below. 

DATA  LINK  ANALYSIS  ROUTINE. 

This  routine  examines  the  transactions 
used  to  handle  each  tactical  uplink 
message.  A  message  transaction  is 
complete  when  a  rejection,  delivery,  or 
expiration  notice  is  returned  to  the 
sender  of  the  message.  A  delayed 
message  may  terminate  in  delivery  if  the 
track  becomes  established  on  roll-call 
in  time,  otherwise  it  expires.  Any 
message  which  is  not  handled  in  one  of 
these  transactions  is  regarded  as 
"lost."  The  following  counts  are 
maintained  by  the  program; 

1.  Number  of  uplinks  delivered  by 
each  sensor 

2.  Number  of  uplinks  expired  at 
each  sensor 

3.  Number  of  uplinks  rejected  by 
each  sensor 

4.  Number  of  uplinks  delayed  at 
each  sensor 


5.  Number  of  uplinks  delivered 
within  i  time  units,  where  a  time 
unit  is  defined  as  the  time  between 
successive  blocks  of  messages,  namely 
5  seconds. 

TRACK  SUMMARY  PROGRAM. 

The  track  summary  program  divides  the 
data  into  functional  subsets  by  message 
rate.  For  each  message  rate  and  for 
each  target  as  seen  by  a  given  sensor, 
the  following  quantities  are  measured: 

1 .  Number  of  scans  in  the  sample 

2.  Number  of  roll-call  scans  in 
the  sample 

3.  Number  of  scans  in  the  zenith 

cone 

4.  Blip/scan  ratio 

DABS  EXTRACTION  TAPE  FILTER  PROGRAM. 

The  sensor  data  extraction  tape  is  used 
as  an  input  to  this  routine.  The 
particular  output  used  in  data  link 
analysis  is  a  scan-by-scan  count  (by 
target)  of  the  number  of  roll-call 
replies  assigned  to  each  of  the  possible 
failure  codes  (valid,  no  monopulse 
received,  no  reply  detected,  and  no 
reply  decoded).  The  no  detect  and  no 
decode  categories  of  reply  are  used  to 
determine  the  number  of  interrogations 
that  tried  (but  failed)  to  deliver  an 
uplink  message  to  the  aircraft.  The 
other  counts  are  used  to  determine  the 
number  of  uplinks  that  were  actually 
delivered . 
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APPENDIX  E 


INTERSENSOR  COMMUNICATIONS 
DATA  REDUCTION 


Dumps  of  sensor-to-sensor  message 
traffic  recorded  at  the  system  test 
console  (STC)  were  made  using  the 
quick  look  STC  extraction  (QSTCE) 


data  reduction  program  on  the  Texas 
Instruments  990  computer  system.  These 
dumps  showed  that  multisite  performance 
monitor  functions  were  being  carried  out 
correctly,  and  the  STC  message  summary 
at  the  end  of  each  QSTCE  run  allowed  a 
rapid  visual  check  of  the  integrity  of 
the  intersensor  message  exchanges  that 
occurred  during  the  testing. 


